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

I'm not entirely sure what you're saying here. Schema::Loader reads the structure of your database to generate DBIC result classes, and it ignores the names of the foreign keys in your database and makes guesses about what the name of the relationship should be based on the column names involved. If you declare one of those naming conventions, it will generate the same names every time, but it has no idea what the relationship name "should" be.

If you have relationships defined in JSON, then why are you using Schema::Loader? You could just generate the DBIC result classes however you like. If you want to pick up the database column names, but define custom relationships, you can do that by putting the relationships below the auto-generated code, and Schema::Loader will preserve all that custom code while re-generating the column definitions.

There is one project where I wanted to retroactively use SchemaLoader, but other developers had already chosen all sorts of names for the relationships, and I needed to preserve that. I ended up writing a very long rel_name_map parameter in my script that runs Schema::Loader to override all its choices of relationship name. i.e.

rel_name_map   => {
      Group => {
         reportnum => 'report',
         rpt_sections => 'sections',
      },
[download]

and so on for ~50 relationships or so. It was annoying and tedious, but let me choose all the specific names I needed to preserve. I don't recommend this really; since you have them in JSON already you could just tell Schema::Loader to ignore foreign keys and then inject the relationships into the generated code yourself with option filter_generated_code.

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

Replies are listed 'Best First'.
Re^2: DBIx::Class : stop changing table, column, relationship names by bliako (Abbot) on Feb 28, 2023 at 18:36 UTC
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.	[reply] [d/l] [select]
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]