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]

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.

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.