Re^2: DBIx::Class : stop changing table, column, relationship names

Thanks for your reply. Perhaps I was a bit vague, so here is some more detail.

No, the JSON data does not contain the relationships. Only table names, and I infer the foreign keys.

Consider the following SQL of two tables where one is referencing the other's PK:

CREATE TABLE MyappType (
  Id INTEGER NOT NULL UNIQUE
  # ...
);
CREATE TABLE AvailableMyapp (
  MyappTypeId INTEGER NOT NULL,
  FOREIGN KEY(MyappTypeId) REFERENCES MyappType(Id)
  # ...
);
[download]

Using:

DBIx::Class::Schema::Loader::make_schema_at(
  'Myapps::Model::Schema',
  skip_load_external => 1,
  naming => {
   monikers => 'preserve',
   #relationships => 'current', 
   column_accessors => 'preserve',
  },
);
[download]

creates following perl in file : Model::Schema::Result::AvailableMyapp

...
__PACKAGE__->has_many(
  "available_myapps",
  "Myapps::Model::Schema::Result::AvailableMyapp",
      {
          "foreign.MyappTypeId" => "self.Id",
      },

      {
          "cascade_copy" => "0",
          "cascade_delete" => "0",
      },
);
[download]

and this perl in file 'Model/Schema/Result/AvailableMyapp.pm':

...
__PACKAGE__->belongs_to(
  "myapp_type",
  "Myapps::Model::Schema::Result::MyappType",

      {
          "Id" => "MyappTypeId",
      },

      {
          "is_deferrable" => "0",
          "on_delete" => "NO ACTION",
          "on_update" => "NO ACTION",
      },
);
[download]

My problem is with the relationship names "available_myapps" and "myapp_type". I don't want the plural in the first one and I don't want to break the camel type for either.

Comment on Re^2: DBIx::Class : stop changing table, column, relationship names Select or Download Code

Replies are listed 'Best First'.
Re^3: DBIx::Class : stop changing table, column, relationship names by NERDVANA (Priest) on Mar 01, 2023 at 09:57 UTC
So you really just want the relationship name to be exactly the name of the table it links to? I think that can be done with `rel_name_map => sub { $_[0]{remote_moniker} }` [download] To clarify some of your earlier questions, the reason that the moniker options were not having the desired effect is that they only affect the class name itself. They are assuming that most people have lowercase table names that might be plural and they assume that the average person wants to convert those to camel-case perl package names that are singular. They never considered that someone might want camel-case relationship names. The reason why most people don't want camel-case relationship names or attribute names is that Perl's naming convention serves an important purpose. There is a namespace clash between a package name A::B and a fully qualified method name A::b and as soon as you start using uppercase method names, you can run into messy name conflicts. You can see this in the documentation of Type::Tiny (or Types::Standard, I forget where exactly) where the author recommends that everyone always call constructors as `"A::B"->new` instead of `A::B->new` because the latter will break if there is a type named "B" imported into the namespace of package "A". Well, the real problem is that Type::Tiny encouraged people to import a bunch of symbols that start with a capital letter and have a high probability of conflicting with a package deeper in the hierarchy, and that those symbols remain in the package if you don't `use namespace::clean;` and then confuse perl's heuristics about whether you are referring to a package or calling a function. For DBIC relations it probably doesn't matter, because nobody is likely to want to define classes within the namespace of a Result class.	[reply] [d/l] [select]
Re^4: DBIx::Class : stop changing table, column, relationship names by bliako (Abbot) on Mar 03, 2023 at 08:39 UTC
Thank you NERDVANA. Your advice produced the result I wanted. If the schema is mine, then tablenames are all lowercase. Having a relationship name same as the table name (as I wanted) simplifies things for me given that there is only 1 relationship to the external table. If more relationships exist to the same table, then it produces the same relationship name for all, which is a very bad side-effect. So, being an eternal DBIx::Class (and SQL) newbie perhaps I should just stick to the defaults. Thanks, bliako	[reply]