skip_relationships

skip_load_external

naming

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

dry_run

generate_pod

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

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

The default is 60

table_comments_table

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

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

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 to on on 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;

            reutrn $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,
    },

For belongs_to relationships, these defaults are overridden by the attributes introspected from the foreign key in the database, if this information is available (and the driver is capable of retrieving it.)

This information overrides the defaults mentioned above, and is then itself overridden by the user's "relationship_attrs" for "belongs_to" if any are specified.

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 is not 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.

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.

debug

db_schema

Can be set to an arrayref of schema names for multiple schemas, or the special value "%" for all schemas.

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.

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.

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

moniker_parts

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.

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.

Below is a table of supported databases and possible "moniker_parts".

• DB2, Firebird, mysql, Oracle, Pg, SQLAnywhere, SQLite, MS Access

  "schema", "name"

• Informix, MSSQL, Sybase ASE

  "database", "schema", "name"

moniker_part_separator

constraint

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.

exclude

The tables to exclude are specified in the same way as for the "constraint" option.

moniker_map

• 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".

• a hashref of unqualified table name keys and moniker values
• a coderef that returns the moniker, which is called with the following arguments:

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.

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

    Table Name       | Moniker Name
    ---------------------------------
    luser            | Luser
    luser_group      | LuserGroup
    luser-opts       | LuserOpt
    stations_visited | StationVisited
    routeChange      | RouteChange

moniker_part_map

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.

col_accessor_map

• 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

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".

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.

inflect_plural

inflect_singular

schema_base_class

schema_components

result_base_class

additional_base_classes

left_base_classes

additional_classes

components

result_components_map

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

You may use this in conjunction with "components".

result_roles

result_roles_map

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

You may use this in conjunction with "result_roles".

use_namespaces

Generate result class names suitable for "load_namespaces" in DBIx::Class::Schema and call that instead of "load_classes" in DBIx::Class::Schema. When 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 will be added to the call (and the generated result class names adjusted appropriately).

dump_directory

The created schema class will have the same classname as the one on which you are setting this option (and the ResultSource classes will be based on this name as well).

Normally you wouldn't hard-code this setting in your schema class, as it is meant for one-time manual usage.

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

dump_overwrite

really_erase_my_files

The default behavior is instead 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 as they were.

When "really_erase_my_files" is not set, if the output file already exists, but the aforementioned final stanza is not found, or the checksum contained there does not match the generated contents, Loader will croak and not touch the file.

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

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

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

omit_version

omit_timestamp

custom_column_info

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

Receives the DBIx::Class::Schema::Loader::Table object, column name and 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".

datetime_timezone

datetime_locale

datetime_undef_if_invalid

The default is recommended to deal with data such as "00/00/00" which sometimes ends up in such columns in MySQL.

config_file

preserve_case

Drivers for case sensitive databases like Sybase ASE or MSSQL with a case-sensitive collation will turn this option on unconditionally.

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

"naming" = "v7" or greater is required with this option.

qualify_objects

This attribute is automatically set to true for multi db_schema configurations, unless explicitly set to false by the user.

use_moose

It is safe to upgrade your existing Schema to this option.

only_autoclean

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

If you don't care about operator overloads, enabling this option falls back to just using namespace::autoclean itself.

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 recommended.

col_collision_map

This option 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

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

uniq_to_primary

allow_extra_m2m_cols

filter_generated_code

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.

    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 will leave the generated code in the default format, but will allow you to tidy your classes at any point in future, without worrying about changing the portions of the file which are checksummed, since "perltidy" will just ignore all text between the markers.

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

new

load

rescan

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".

get_dump_filename

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

tables

monikers

classes

generated_classes