DBIx::C...er::Base(3)

💖 NAME 💖

okay bestie, welcome to the DBIx::Class::Schema::Loader::Base(3) page from User Contributed Perl Documentation. This is the base implementation for DBIx::Class::Schema::Loader — the whole foundation vibe. 🫶

---

✨ SYNOPSIS ✨

See DBIx::Class::Schema::Loader.

---

🦋 DESCRIPTION 🦋

This is the base class for the storage-specific DBIx::Class::Schema::* classes, and it implements the common functionality between them. Basically: shared load-bearing code, and it ate. 💅

---

🎀 CONSTRUCTOR OPTIONS 🎀

These constructor options are the base options for loader_options in DBIx::Class::Schema::Loader. Available constructor options are:

💅 skip_relationships

Skip setting up relationships. The default is to attempt the loading of relationships. no cap.

🦋 skip_load_external

Skip loading of other classes in @INC. The default is to merge all other classes with the same name found in @INC into the schema file we are creating.

🌸 naming

Static schemas (ones dumped to disk) will, by default, use the new-style relationship names and singularized Results, unless you're overwriting an existing dump made by an older version of DBIx::Class::Schema::Loader, in which case the backward compatible RelBuilder will be activated, and the appropriate monikerization used.

Specifying

naming => 'current'

will disable the backward-compatible RelBuilder and use the new-style relationship names along with singularized Results, even when overwriting a dump made with an earlier version.

The option also takes a hashref:

naming => {
    relationships    => 'v8',
    monikers         => 'v8',
    column_accessors => 'v8',
    force_ascii      => 1,
}

or

naming => { ALL => 'v8', force_ascii => 1 }

The keys are:

• ALL — Set relationships, monikers and column_accessors to the specified value.
• relationships — How to name relationship accessors.
• monikers — How to name Result classes.
• column_accessors — How to name column accessors in Result classes.
• force_ascii — For v8 mode and later, uses String::ToIdentifier::EN instead of String::ToIdentifier::EN::Unicode to force monikers and other identifiers to ASCII.

The values can be:

• current — Latest style, whatever that happens to be.
• v4 — Unsingularlized monikers, has_many only relationships with no _id stripping.
• v5 — Monikers singularized as whole words, might_have relationships for FKs on UNIQUE constraints, _id stripping for belongs_to relationships.

Some of the _id stripping edge cases in 0.05003 have been reverted for the v5 RelBuilder.

• v6 — All monikers and relationships are inflected using Lingua::EN::Inflect::Phrase, and there is more aggressive _id stripping from relationship names.

In general, there is very little difference between v5 and v6 schemas.

• v7 — This mode is identical to v6 mode, except that monikerization of CamelCase table names is also done better (but best in v8.)

CamelCase column names in case-preserving mode will also be handled better for relationship name inflection (but best in v8.) See preserve_case.

In this mode, CamelCase column_accessors are normalized based on case transition instead of just being lowercased, so FooId becomes foo_id.

• v8 — (EXPERIMENTAL)

The default mode is v7, to get v8 mode, you have to specify it in naming explicitly until 0.08 comes out.

monikers and column_accessors are created using String::ToIdentifier::EN::Unicode or String::ToIdentifier::EN if force_ascii is set; this is only significant for names with non-\w characters such as ..

CamelCase identifiers with words in all caps, e.g. VLANValidID are supported correctly in this mode.

For relationships, belongs_to accessors are made from column names by stripping postfixes other than _id as well, for example just Id, _?ref, _?cd, _?code and _?num, case insensitively.

• preserve — For monikers, this option does not inflect the table names but makes monikers based on the actual name. For column_accessors this option does not normalize CamelCase column names to lowercase column accessors, but makes accessors that are the same names as the columns (with any non-\w chars replaced with underscores.)
• singular — For monikers, singularizes the names using the most current inflector. This is the same as setting the option to current.
• plural — For monikers, pluralizes the names, using the most current inflector.

Dynamic schemas will always default to the 0.04XXX relationship names and won't singularize Results for backward compatibility, to activate the new RelBuilder and singularization put this in your Schema.pm file:

__PACKAGE__->naming('current');

Or if you prefer to use 0.07XXX features but insure that nothing breaks in the next major version upgrade:

__PACKAGE__->naming('v7');

🌈 quiet

If true, will not print the usual "Dumping manual schema ... Schema dump completed." messages. Does not affect warnings (except for warnings related to really_erase_my_files.)

🍓 dry_run

If true, don't actually write out the generated files. This can only be used with static schema generation.

🧚 generate_pod

By default POD will be generated for columns and relationships, using database metadata for the text if available and supported.

Comment metadata can be stored in two ways.

The first is that you can create two tables named table_comments and column_comments respectively. These tables must exist in the same database and schema as the tables they describe. They both need to have columns named table_name and comment_text. The second one needs to have a column named column_name. Then data stored in these tables will be used as a source of metadata about tables and comments.

(If you wish you can change the name of these tables with the parameters table_comments_table and column_comments_table.)

As a fallback you can use built-in commenting mechanisms. Currently this is only supported for PostgreSQL, Oracle and MySQL. To create comments in PostgreSQL you add statements of the form COMMENT ON TABLE some_table IS '...', the same syntax is used in Oracle. To create comments in MySQL you add COMMENT '...' to the end of the column or table definition. Note that MySQL restricts the length of comments, and also does not handle complex Unicode characters properly.

Set this to 0 to turn off all POD generation.

💜 pod_comment_mode

Controls where table comments appear in the generated POD. Smaller table comments are appended to the NAME section of the documentation, and larger ones are inserted into DESCRIPTION instead. You can force a DESCRIPTION section to be generated with the comment always, only use NAME, or choose the length threshold at which the comment is forced into the description.

• name — Use NAME section only.
• description — Force DESCRIPTION always.
• auto — Use DESCRIPTION if length > pod_comment_spillover_length, this is the default.

⭐ pod_comment_spillover_length

When pod_comment_mode is set to auto, this is the length of the comment at which it will be forced into a separate description section.

The default is 60

🎀 table_comments_table

The table to look for comments about tables in. By default table_comments. See generate_pod for details.

This must not be a fully qualified name, the table will be looked for in the same database and schema as the table whose comment is being retrieved.

🦋 column_comments_table

The table to look for comments about columns in. By default column_comments. See generate_pod for details.

This must not be a fully qualified name, the table will be looked for in the same database and schema as the table/column whose comment is being retrieved.

🔥 relationship_attrs

Hashref of attributes to pass to each generated relationship, listed by type. Also supports relationship type 'all', containing options to pass to all generated relationships. Attributes set for more specific relationship types override those set in 'all', and any attributes specified by this option override the introspected attributes of the foreign key if any.

For example:

relationship_attrs => {
    has_many   => { cascade_delete => 1, cascade_copy => 1 },
    might_have => { cascade_delete => 1, cascade_copy => 1 },
},

use this to turn DBIx::Class cascades on for your has_many and might_have relationships — they default to off.

Can also be a coderef, for more precise control, in which case the coderef gets this hash of parameters (as a list):

rel_name        # the name of the relationship
rel_type        # the type of the relationship: 'belongs_to', 'has_many' or 'might_have'
local_source    # the DBIx::Class::ResultSource object for the source the rel is *from*
remote_source   # the DBIx::Class::ResultSource object for the source the rel is *to*
local_table     # the DBIx::Class::Schema::Loader::Table object for the table of the source the rel is from
local_cols      # an arrayref of column names of columns used in the rel in the source it is from
remote_table    # the DBIx::Class::Schema::Loader::Table object for the table of the source the rel is to
remote_cols     # an arrayref of column names of columns used in the rel in the source it is to
attrs           # the attributes that would be set

it should return the new hashref of attributes, or nothing for no changes.

For example:

relationship_attrs => sub {
    my %p = @_;

    say "the relationship name is: $p{rel_name}";
    say "the relationship is a: $p{rel_type}";
    say "the local class is: ",  $p{local_source}->result_class;
    say "the remote class is: ", $p{remote_source}->result_class;
    say "the local table is: ", $p{local_table}->sql_name;
    say "the rel columns in the local table are: ", (join ", ", @{$p{local_cols}});
    say "the remote table is: ", $p{remote_table}->sql_name;
    say "the rel columns in the remote table are: ", (join ", ", @{$p{remote_cols}});

    if ($p{local_table} eq 'dogs' && @{$p{local_cols}} == 1 && $p{local_cols}[0] eq 'name') {
        $p{attrs}{could_be_snoopy} = 1;

        return $p{attrs};
    }
},

These are the default attributes:

           has_many => {
               cascade_delete => 0,
               cascade_copy   => 0,
           },
           might_have => {
               cascade_delete => 0,
               cascade_copy   => 0,
           },
           belongs_to => {
               on_delete => 'CASCADE',
               on_update => 'CASCADE',
               is_deferrable => 1,
           },

okay so for belongs_to relationships, those cute lil defaults get overridden by the attributes introspected from the foreign key in the database, if that info is even available (and if the driver can actually retrieve it 👀).

That introspected info overrides the defaults we just mentioned, and then it gets overridden again by your own relationship_attrs for belongs_to, if you specified any. Layers on layers bestie 💅

In general, for most databases, for a plain foreign key with no rules, the values for a belongs_to relationship will be:

           on_delete     => 'NO ACTION',
           on_update     => 'NO ACTION',
           is_deferrable => 0,

In the cases where an attribute isn't supported by the DB, a value matching the actual behavior is used — for example Oracle does not support ON UPDATE rules, so on_update is set to NO ACTION. This is done so that the behavior of the schema is preserved when cross deploying to a different RDBMS such as SQLite for testing. iykyk 🧚

In the cases where the DB does not support DEFERRABLE foreign keys, the value is set to 1 if DBIx::Class has a working $storage->with_deferred_fk_checks. This is done so that the same DBIx::Class code can be used, and cross deployed from and to such databases. no cap 💖

---

🐛 debug

If set to true, each constructive DBIx::Class statement the loader decides to execute will be warn-ed before execution. literally narrating its own moves, main character energy 🌟

🗂️ db_schema

Set the name of the schema to load (schema in the sense that your database vendor means it). yes, everyone means something different, it's giving chaos 🙈

Can be set to an arrayref of schema names for multiple schemas, or the special value % for all schemas. all of them. every single one 💀

For MSSQL, Sybase ASE, and Informix can be set to a hashref of databases as keys and arrays of owners as values, set to the value:

           { '%' => '%' }

for all owners in all databases. wild, I know 🦋

Name clashes resulting from the same table name in different databases/schemas will be resolved automatically by prefixing the moniker with the database and/or schema. the loader handles the drama so you don't have to 💅

To prefix/suffix all monikers with the database and/or schema, see moniker_parts. 👀

🧩 moniker_parts

The database table names are represented by the DBIx::Class::Schema::Loader::Table class in the loader, the DBIx::Class::Schema::Loader::Table::Sybase class for Sybase ASE and DBIx::Class::Schema::Loader::Table::Informix for Informix. so many classes, so little time 🎀

Monikers are created normally based on just the name property, corresponding to the table name, but can consist of other parts of the fully qualified name of the table. glow-up for your monikers fr fr ✨

The moniker_parts option is an arrayref of methods on the table class corresponding to parts of the fully qualified table name, defaulting to ['name'], in the order those parts are used to create the moniker name. The parts are joined together using moniker_part_separator. 🫶

The 'name' entry must be present. non-negotiable bestie 👑

Below is a table of supported databases and possible moniker_parts. (okay it was a table, now it's a list, same facts tho 💖)

• DB2, Firebird, mysql, Oracle, Pg, SQLAnywhere, SQLite, MS Access — schema, name
• Informix, MSSQL, Sybase ASE — database, schema, name

🔗 moniker_part_separator

String used to join moniker_parts when creating the moniker. Defaults to the empty string. Use :: to get a separate namespace per database and/or schema. cute lil separator, big job 🌸

🚧 constraint

Only load matching tables.

These can be specified either as a regex (preferably on the qr// form), or as an arrayref of arrayrefs. Regexes are matched against the (unqualified) table name, while arrayrefs are matched according to moniker_parts. 🎯

For example:

           db_schema => [qw(some_schema other_schema)],
           moniker_parts => [qw(schema name)],
           constraint => [
               [ qr/\Asome_schema\z/ => qr/\A(?:foo|bar)\z/ ],
               [ qr/\Aother_schema\z/ => qr/\Abaz\z/ ],
           ],

In this case only the tables foo and bar in some_schema and baz in other_schema will be dumped. everyone else? not invited to the party 🙅‍♀️

🚫 exclude

Exclude matching tables.

The tables to exclude are specified in the same way as for the constraint option. same syntax, opposite vibe 💅

🏷️ moniker_map

Overrides the default table name to moniker translation. Either:

• a nested hashref, which will be traversed according to moniker_parts

For example:

             moniker_parts => [qw(schema name)],
             moniker_map => {
                 foo => {
                     bar  => "FooishBar",
                 },
             },

In which case the table bar in the foo schema would get the moniker FooishBar. slay 🎀

• a hashref of unqualified table name keys and moniker values
• a coderef that returns the moniker, which is called with the following arguments:
  • the DBIx::Class::Schema::Loader::Table object for the table
  • the default moniker that DBIC would ordinarily give this table
  • a coderef that can be called with either of the hashref forms to get the moniker mapped accordingly. This is useful if you need to handle some monikers specially, but want to use the hashref form for the rest.

If the hash entry does not exist, or the function returns a false value, the code falls back to default behavior for that table name. it just shrugs and does the normal thing 🤷‍♀️

The default behavior is to split on case transition and non-alphanumeric boundaries, singularize the resulting phrase, then join the titlecased words together. Examples:

• luser → Luser
• luser_group → LuserGroup
• luser-opts → LuserOpt
• stations_visited → StationVisited
• routeChange → RouteChange

see? it ate 💅

🗺️ moniker_part_map

Map for overriding the monikerization of individual moniker_parts. The keys are the moniker part to override, the value is either a hashref or coderef for mapping the corresponding part of the moniker. If a coderef is used, it gets called with the moniker part and the hash key the code ref was found under. 🦋

For example:

           moniker_part_map => {
               schema => sub { ... },
           },

Given the table foo.bar, the code ref would be called with the arguments foo and schema, plus a coderef similar to the one described in moniker_map. 🫶

moniker_map takes precedence over this. precedence drama, but make it fair ⭐

🔤 col_accessor_map

Same as moniker_map, but for column accessor names. The nested hashref form is traversed according to moniker_parts, with an extra level at the bottom for the column name. If a coderef is passed, the code is called with the following arguments:

• the DBIx::Class::Schema::Loader::Column object for the column
• the default accessor name that DBICSL would ordinarily give this column
• a hashref of this form:

             {
                 table_class     => name of the DBIC class we are building,
                 table_moniker   => calculated moniker for this table (after moniker_map if present),
                 table           => the DBIx::Class::Schema::Loader::Table object for the table,
                 full_table_name => schema-qualified name of the database table (RDBMS specific),
                 schema_class    => name of the schema class we are building,
                 column_info     => hashref of column info (data_type, is_nullable, etc),
             }

• a coderef that can be called with a hashref map

💞 rel_name_map

Similar in idea to moniker_map, but different in the details. It can be a hashref or a code ref. 👀

If it is a hashref, keys can be either the default relationship name, or the moniker. The keys that are the default relationship name should map to the name you want to change the relationship to. Keys that are monikers should map to hashes mapping relationship names to their translation. You can do both at once, and the more specific moniker version will be picked up first. So, for instance, you could have:

           {
               bar => "baz",
               Foo => {
                   bar => "blat",
               },
           }

and relationships that would have been named bar will now be named baz except that in the table whose moniker is Foo it will be named blat. very specific, very demure 🎀

If it is a coderef, it will be passed a hashref of this form:

           {
               name           => default relationship name,
               type           => the relationship type eg: C<has_many>,
               local_class    => name of the DBIC class we are building,
               local_moniker  => moniker of the DBIC class we are building,
               local_columns  => columns in this table in the relationship,
               remote_class   => name of the DBIC class we are related to,
               remote_moniker => moniker of the DBIC class we are related to,
               remote_columns => columns in the other table in the relationship,
               # for type => "many_to_many" only:
               link_class     => name of the DBIC class for the link table,
               link_moniker   => moniker of the DBIC class for the link table,
               link_rel_name  => name of the relationship to the link table,
           }

In addition it is passed a coderef that can be called with a hashref map. 🫶

DBICSL will try to use the value returned as the relationship name. it's trying its best and honestly? it's doing great 💖

🔢 inflect_plural

Just like moniker_map above (can be hash/code-ref, falls back to default if hash key does not exist or coderef returns false), but acts as a map for pluralizing relationship names. The default behavior is to utilize to_PL in Lingua::EN::Inflect::Phrase. making things plural, iconic 🌈

1️⃣ inflect_singular

As inflect_plural above, but for singularizing relationship names. Default behavior is to utilize to_S in Lingua::EN::Inflect::Phrase. ok the pair is complete, balance restored ✨

🏛️ schema_base_class

Base class for your schema classes. Defaults to 'DBIx::Class::Schema'. the blueprint, the foundation, the moment 👑

🧱 schema_components

List of components to load into the Schema class. stack 'em up 🎀

🧬 result_base_class

Base class for your table classes (aka result classes). Defaults to 'DBIx::Class::Core'. yes bestie, table classes are also called result classes, keep up 💅

➕ additional_base_classes

List of additional base classes all of your table classes will use. more bases, more power 🦋

⬅️ left_base_classes

List of additional base classes all of your table classes will use that need to be leftmost. leftmost is a whole personality trait apparently 🙈

🎁 additional_classes

List of additional classes which all of your table classes will use.

🧩 components

List of additional components to be loaded into all of your Result classes. A good example would be InflateColumn::DateTime. cute, useful, does numbers and dates 🍓

🎛️ result_components_map

A hashref of moniker keys and component values. Unlike components, which loads the given components into every Result class, this option allows you to load certain components for specified Result classes. For example:

           result_components_map => {
               StationVisited => '+YourApp::Schema::Component::StationVisited',
               RouteChange    => [
                                     '+YourApp::Schema::Component::RouteChange',
                                     'InflateColumn::DateTime',
                                 ],
           }

And yeah — you can totally use this alongside components, bestie 💖

result_roles

A list of Moose roles that get applied to, like, every single one of your Result classes. All of them. Periodt 👑

result_roles_map

A hashref of moniker keys pointing at role values. Okay so here's the difference from result_roles: that one slaps the given roles on every Result class no questions asked, but this one is the picky version — you get to apply certain roles to specified Result classes only. Very choosey, very main character. For example:

    result_roles_map => {
        StationVisited => [
                              'YourApp::Role::Building',
                              'YourApp::Role::Destination',
                          ],
        RouteChange    => 'YourApp::Role::TripEvent',
    }

And yes, you can absolutely use this in conjunction with result_roles 🫶

use_namespaces

This is the default now bestie — if you wanna crawl back to load_classes in DBIx::Class::Schema, just pass a 0.

What it does: it generates result class names that are suitable for load_namespaces in DBIx::Class::Schema, and then calls that instead of load_classes in DBIx::Class::Schema. And the cute part — when you're using this option you can also specify any of the options for load_namespaces (i.e. result_namespace, resultset_namespace, default_resultset_class), and they get added to the call (with the generated result class names adjusted to match, obviously 💅).

dump_directory

The value here is a perl libdir pathname. Inside that directory, this module will create a baseline manual DBIx::Class::Schema module set, based on whatever it builds at runtime.

The created schema class gets the same classname as the one you're setting this option on (and the ResultSource classes are based on that name too, slay).

Normally you wouldn't hard-code this setting in your schema class, because it's meant for one-time manual usage, okay? Don't be weird about it.

See dump_to_dir in DBIx::Class::Schema::Loader for examples of the recommended way to access this functionality ✨

dump_overwrite

Deprecated 🚩 See really_erase_my_files below — and heads up, that one does not mean the same thing as the old dump_overwrite setting from previous releases. They are different things, do not confuse them.

really_erase_my_files

Default is false. If you set it true, Loader will unconditionally delete any existing files before creating the new ones from scratch when dumping a schema to disk. Unconditional. No takebacks.

The default behavior instead is to only replace the top portion of the file — up to and including the final stanza which contains # DO NOT MODIFY THE FIRST PART OF THIS FILE — leaving any customizations you placed after that exactly as they were 💖

When really_erase_my_files is not set: if the output file already exists but that aforementioned final stanza isn't found, or the checksum contained there doesn't match the generated contents, Loader will croak and won't touch the file at all.

Okay, real talk: you should really be using version control on your schema classes (and all of the rest of your code for that matter). Don't blame me if a bug in this code wipes something out when it shouldn't have — you've been warned 😭

overwrite_modifications

Default false. When it's false and Loader is updating existing files, it will refuse to modify any Loader-generated code that's been modified since its last run (as determined by the checksum Loader puts in its comment lines). It's got receipts 🧾

If true, Loader will discard any manual modifications that have been made to Loader-generated code. All of them. Gone.

Again — you should be using version control on your schema classes. Be careful with this option, fr fr 🙈

omit_version

Omit the package version from the signature comment. That's it, that's the whole thing ✨

omit_timestamp

Omit the creation timestamp from the signature comment. Also just that 🎀

custom_column_info

A hook for adding extra attributes to the column_info for a column 💅

Must be a coderef that returns a hashref with the extra attributes.

It receives the DBIx::Class::Schema::Loader::Table object, the column name, and the column_info.

For example:

    custom_column_info => sub {
        my ($table, $column_name, $column_info) = @_;

        if ($column_name eq 'dog' && $column_info->{default_value} eq 'snoopy') {
            return { is_snoopy => 1 };
        }
    },

This attribute can also be used to set inflate_datetime on a non-datetime column, so it also receives the datetime_timezone and/or datetime_locale. Sneaky but iconic 🐶

datetime_timezone

Sets the timezone attribute for DBIx::Class::InflateColumn::DateTime for all columns with the DATE/DATETIME/TIMESTAMP data_types 🌍

datetime_locale

Sets the locale attribute for DBIx::Class::InflateColumn::DateTime for all columns with the DATE/DATETIME/TIMESTAMP data_types 🌏

datetime_undef_if_invalid

Pass a 0 for this option when using MySQL if you DON'T want datetime_undef_if_invalid => 1 in your column info for DATE, DATETIME and TIMESTAMP columns.

The default is recommended, because it deals with data such as "00/00/00" which sometimes ends up in such columns in MySQL. Yeah. It's giving cursed data 😭

config_file

A file in Perl format, which should return a HASH reference, from which to read loader options 📄

preserve_case

Normally database names get lowercased and split by underscore. Use this option if you have CamelCase database names, bestie 🐪

Drivers for case sensitive databases like Sybase ASE or MSSQL with a case-sensitive collation will turn this option on unconditionally. Not optional for them, they just do it.

NOTE: naming = v8 is highly recommended with this option, because the semantics of this mode are much improved for CamelCase database names.

And naming = v7 or greater is required with this option. Not a suggestion, a requirement 🔥

qualify_objects

Set it to true to prepend the db_schema to table names for __PACKAGE__->table calls, and to some other things like Oracle sequences.

This attribute is automatically set to true for multi db_schema configurations — unless you explicitly set it to false, in which case, your call 👑

use_moose

Creates Schema and Result classes that use Moose, MooseX::NonMoose and MooseX::MarkAsMethods (or namespace::autoclean — see below). The default content after the md5 sum also makes the classes immutable. Fancy ✨

It is safe to upgrade your existing Schema to this option. No cap 🫶

only_autoclean

By default we use MooseX::MarkAsMethods to remove imported functions from your generated classes. It uses namespace::autoclean to do this, after telling your object's metaclass that any operator overloads in your class are methods — which causes namespace::autoclean to spare them from removal.

This prevents the "Hey, where'd my overloads go?!" effect. Genuinely the worst feeling 😤

If you don't care about operator overloads (or if you know your Moose is at at least version 2.1400, where MooseX::MarkAsMethods is no longer necessary), enabling this option falls back to just using namespace::autoclean itself.

And if none of the above made any sense, or you don't have some pressing need to only use namespace::autoclean — leaving this set to the default is just fine. Truly, it's fine, breathe 💜

col_collision_map

This option controls how accessors for column names which collide with perl methods are named. See "COLUMN ACCESSOR COLLISIONS" for more information.

It takes either a single sprintf format, or a hashref of strings which are compiled to regular expressions that map to sprintf formats.

Examples:

    col_collision_map => 'column_%s'

    col_collision_map => { '(.*)' => 'column_%s' }

    col_collision_map => { '(foo).*(bar)' => 'column_%s_%s' }

rel_collision_map

Works just like col_collision_map, but for relationship names/accessors rather than column names/accessors 💫

The default is to just append _rel to the relationship name — see "RELATIONSHIP NAME COLLISIONS".

uniq_to_primary

Automatically promotes the largest unique constraints with non-nullable columns on tables to primary keys — assuming there's only one largest unique constraint. If there's a tie, it's not gonna pick favorites 🏆

allow_extra_m2m_cols

Generate many_to_many relationship bridges even if the link table has extra columns other than the foreign keys. The primary key must still equal the union of the foreign keys though — that part's non-negotiable 💅

filter_generated_code

An optional hook that lets you filter the generated text for various classes through a function that changes it in any way you want. The function receives the type of file, "schema" or "result", the class, and the code; and returns the new code to use instead. So like — you could add custom comments, or do literally anything else you want. Go off 🎨

The option can also be set to a string, which is then used as a filter program, e.g. "perltidy".

If this exists but fails to return text matching /\bpackage\b/, no file will be generated. Important detail, don't miss it 🚩

    filter_generated_code => sub {
        my ($type, $class, $text) = @_;
        ...
        return $new_code;
    }

You can also use this option to set perltidy markers in your generated classes. This leaves the generated code in the default format, but lets you tidy your classes at any point in the future without worrying about changing the portions of the file which are checksummed — since perltidy will just ignore all text between the markers. Big brain move fr fr 🧠

    filter_generated_code => sub {
        return "#<<<\n$_[2]\n#>>>";
    }

---

🌈 METHODS 🌈

Okay so, none of these methods are intended for direct invocation by regular users of DBIx::Class::Schema::Loader. Some of them are proxied via DBIx::Class::Schema::Loader. You've been told 👀

new

Constructor for DBIx::Class::Schema::Loader::Base, used internally by DBIx::Class::Schema::Loader. Internal business only 🔧

load

Does the actual schema-construction work. The whole point of the thing, honestly 👑

rescan

Arguments: schema

Rescan the database for changes. Returns a list of the newly added table monikers ✨

The schema argument should be the schema class or object to be affected. It should probably be derived from the original schema_class used during load. Probably. Just saying 💅

get_dump_filename

Arguments: class

Returns the full path to the file for a class that has been or will be dumped to. For a dynamic schema, this is a file in a temp dir 📁

tables

Returns a sorted list of loaded tables, using the original database table names. Sorted, original, no remixing 🎀

monikers

Returns a hashref of loaded table → moniker mappings. You'll get two entries for each table — the original name and the "normalized" name — in the case that the two are different (like databases that enjoy uppercase table names, or preserve your original mixed-case definitions, or what-have-you). Two for one, a lil deal 🛍️

classes

Returns a hashref of table → class mappings. In some cases it'll contain multiple entries per table for the original and normalized table names, same as up in monikers 💖

generated_classes

Returns an arrayref of classes that were actually generated — i.e. not skipped because there were no changes. Only the ones who showed up and did the work 🌟

🌍 NON-ENGLISH DATABASES 🌍

okay so bestie, if you're loading a database where the table and column names are in a language that is not English, you're gonna want to turn off the English-language-specific heuristics. they're just guessing at English vibes and they will lowkey embarrass you. 💀

to do that, drop something like this in your loader options:

    naming           => { monikers => 'v4' },
    inflect_singular => sub { "$_[0]_rel" },
    inflect_plural   => sub { "$_[0]_rel" },

slay. no more English-only assumptions. 💅

---

💥 COLUMN ACCESSOR COLLISIONS 💥

every once in a while you'll have a column name that collides with a Perl method — the classic example is can. rude, honestly. 😭 in those cases, the default action is to set the accessor of the column spec to undef.

then you get to name the accessor yourself, bestie. just place code like this below the md5:

    __PACKAGE__->add_column('+can' => { accessor => 'my_can' });

another option is to use the col_collision_map option. pick your fighter. ✨

---

🦋 RELATIONSHIP NAME COLLISIONS 🦋

in very rare cases, you may get a collision between a generated relationship name and a method in your Result class. for example, if you have a foreign key called belongs_to. not me crying at the naming choices. 🙈

this is a problem because relationship names are also relationship accessor methods in DBIx::Class. so yeah, they matter. 💀

the default behavior is to append _rel to the relationship name and print out a warning that refers to this text. so if you see the warning, you know exactly where to look. 🎀

you can also control the renaming with the rel_collision_map option. iconic. 👑

---

👀 SEE ALSO 👀

• DBIx::Class::Schema::Loader
• dbicdump

go read those if you want the full lore. iykyk. 🌈

---

🫶 AUTHORS 🫶

see "AUTHORS" in DBIx::Class::Schema::Loader.

---

📜 LICENSE 📜

this library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

---

and that's the whole page, bestie! 💖 this was perl v5.42.0, dated 2025-07-25, from DBIx::Class::Schema::Loader::Base(3) — you ate that. periodt. 💅✨