1DBIx::Class::Schema::LoUasdeerr:C:oBnatsrei(b3u)ted PerlDBDIoxc:u:mCelnatsast:i:oSnchema::Loader::Base(3)
2
3
4

NAME

6       DBIx::Class::Schema::Loader::Base - Base DBIx::Class::Schema::Loader
7       Implementation.
8

SYNOPSIS

10       See DBIx::Class::Schema::Loader.
11

DESCRIPTION

13       This is the base class for the storage-specific
14       "DBIx::Class::Schema::*" classes, and implements the common
15       functionality between them.
16

CONSTRUCTOR OPTIONS

18       These constructor options are the base options for "loader_options" in
19       DBIx::Class::Schema::Loader.  Available constructor options are:
20
21   skip_relationships
22       Skip setting up relationships.  The default is to attempt the loading
23       of relationships.
24
25   skip_load_external
26       Skip loading of other classes in @INC. The default is to merge all
27       other classes with the same name found in @INC into the schema file we
28       are creating.
29
30   naming
31       Static schemas (ones dumped to disk) will, by default, use the new-
32       style relationship names and singularized Results, unless you're
33       overwriting an existing dump made by an older version of
34       DBIx::Class::Schema::Loader, in which case the backward compatible
35       RelBuilder will be activated, and the appropriate monikerization used.
36
37       Specifying
38
39           naming => 'current'
40
41       will disable the backward-compatible RelBuilder and use the new-style
42       relationship names along with singularized Results, even when
43       overwriting a dump made with an earlier version.
44
45       The option also takes a hashref:
46
47           naming => {
48               relationships    => 'v8',
49               monikers         => 'v8',
50               column_accessors => 'v8',
51               force_ascii      => 1,
52           }
53
54       or
55
56           naming => { ALL => 'v8', force_ascii => 1 }
57
58       The keys are:
59
60       ALL Set "relationships", "monikers" and "column_accessors" to the
61           specified value.
62
63       relationships
64           How to name relationship accessors.
65
66       monikers
67           How to name Result classes.
68
69       column_accessors
70           How to name column accessors in Result classes.
71
72       force_ascii
73           For "v8" mode and later, uses String::ToIdentifier::EN instead of
74           String::ToIdentifier::EN::Unicode to force monikers and other
75           identifiers to ASCII.
76
77       The values can be:
78
79       current
80           Latest style, whatever that happens to be.
81
82       v4  Unsingularlized monikers, "has_many" only relationships with no _id
83           stripping.
84
85       v5  Monikers singularized as whole words, "might_have" relationships
86           for FKs on "UNIQUE" constraints, "_id" stripping for belongs_to
87           relationships.
88
89           Some of the "_id" stripping edge cases in 0.05003 have been
90           reverted for the v5 RelBuilder.
91
92       v6  All monikers and relationships are inflected using
93           Lingua::EN::Inflect::Phrase, and there is more aggressive "_id"
94           stripping from relationship names.
95
96           In general, there is very little difference between v5 and v6
97           schemas.
98
99       v7  This mode is identical to "v6" mode, except that monikerization of
100           CamelCase table names is also done better (but best in v8.)
101
102           CamelCase column names in case-preserving mode will also be handled
103           better for relationship name inflection (but best in v8.) See
104           "preserve_case".
105
106           In this mode, CamelCase "column_accessors" are normalized based on
107           case transition instead of just being lowercased, so "FooId"
108           becomes "foo_id".
109
110       v8  (EXPERIMENTAL)
111
112           The default mode is "v7", to get "v8" mode, you have to specify it
113           in "naming" explicitly until 0.08 comes out.
114
115           "monikers" and "column_accessors" are created using
116           String::ToIdentifier::EN::Unicode or String::ToIdentifier::EN if
117           "force_ascii" is set; this is only significant for names with
118           non-"\w" characters such as ".".
119
120           CamelCase identifiers with words in all caps, e.g. "VLANValidID"
121           are supported correctly in this mode.
122
123           For relationships, belongs_to accessors are made from column names
124           by stripping postfixes other than "_id" as well, for example just
125           "Id", "_?ref", "_?cd", "_?code" and "_?num", case insensitively.
126
127       preserve
128           For "monikers", this option does not inflect the table names but
129           makes monikers based on the actual name. For "column_accessors"
130           this option does not normalize CamelCase column names to lowercase
131           column accessors, but makes accessors that are the same names as
132           the columns (with any non-\w chars replaced with underscores.)
133
134       singular
135           For "monikers", singularizes the names using the most current
136           inflector. This is the same as setting the option to "current".
137
138       plural
139           For "monikers", pluralizes the names, using the most current
140           inflector.
141
142       Dynamic schemas will always default to the 0.04XXX relationship names
143       and won't singularize Results for backward compatibility, to activate
144       the new RelBuilder and singularization put this in your "Schema.pm"
145       file:
146
147           __PACKAGE__->naming('current');
148
149       Or if you prefer to use 0.07XXX features but insure that nothing breaks
150       in the next major version upgrade:
151
152           __PACKAGE__->naming('v7');
153
154   quiet
155       If true, will not print the usual "Dumping manual schema ... Schema
156       dump completed." messages. Does not affect warnings (except for
157       warnings related to "really_erase_my_files".)
158
159   dry_run
160       If true, don't actually write out the generated files.  This can only
161       be used with static schema generation.
162
163   generate_pod
164       By default POD will be generated for columns and relationships, using
165       database metadata for the text if available and supported.
166
167       Comment metadata can be stored in two ways.
168
169       The first is that you can create two tables named "table_comments" and
170       "column_comments" respectively. These tables must exist in the same
171       database and schema as the tables they describe. They both need to have
172       columns named "table_name" and "comment_text". The second one needs to
173       have a column named "column_name". Then data stored in these tables
174       will be used as a source of metadata about tables and comments.
175
176       (If you wish you can change the name of these tables with the
177       parameters "table_comments_table" and "column_comments_table".)
178
179       As a fallback you can use built-in commenting mechanisms.  Currently
180       this is only supported for PostgreSQL, Oracle and MySQL.  To create
181       comments in PostgreSQL you add statements of the form COMMENT ON TABLE
182       some_table IS '...', the same syntax is used in Oracle. To create
183       comments in MySQL you add "COMMENT '...'" to the end of the column or
184       table definition.  Note that MySQL restricts the length of comments,
185       and also does not handle complex Unicode characters properly.
186
187       Set this to 0 to turn off all POD generation.
188
189   pod_comment_mode
190       Controls where table comments appear in the generated POD. Smaller
191       table comments are appended to the "NAME" section of the documentation,
192       and larger ones are inserted into "DESCRIPTION" instead. You can force
193       a "DESCRIPTION" section to be generated with the comment always, only
194       use "NAME", or choose the length threshold at which the comment is
195       forced into the description.
196
197       name
198           Use "NAME" section only.
199
200       description
201           Force "DESCRIPTION" always.
202
203       auto
204           Use "DESCRIPTION" if length > "pod_comment_spillover_length", this
205           is the default.
206
207   pod_comment_spillover_length
208       When pod_comment_mode is set to "auto", this is the length of the
209       comment at which it will be forced into a separate description section.
210
211       The default is 60
212
213   table_comments_table
214       The table to look for comments about tables in.  By default
215       "table_comments".  See "generate_pod" for details.
216
217       This must not be a fully qualified name, the table will be looked for
218       in the same database and schema as the table whose comment is being
219       retrieved.
220
221   column_comments_table
222       The table to look for comments about columns in.  By default
223       "column_comments".  See "generate_pod" for details.
224
225       This must not be a fully qualified name, the table will be looked for
226       in the same database and schema as the table/column whose comment is
227       being retrieved.
228
229   relationship_attrs
230       Hashref of attributes to pass to each generated relationship, listed by
231       type.  Also supports relationship type 'all', containing options to
232       pass to all generated relationships.  Attributes set for more specific
233       relationship types override those set in 'all', and any attributes
234       specified by this option override the introspected attributes of the
235       foreign key if any.
236
237       For example:
238
239           relationship_attrs => {
240               has_many   => { cascade_delete => 1, cascade_copy => 1 },
241               might_have => { cascade_delete => 1, cascade_copy => 1 },
242           },
243
244       use this to turn DBIx::Class cascades to on on your has_many and
245       might_have relationships, they default to off.
246
247       Can also be a coderef, for more precise control, in which case the
248       coderef gets this hash of parameters (as a list):
249
250           rel_name        # the name of the relationship
251           rel_type        # the type of the relationship: 'belongs_to', 'has_many' or 'might_have'
252           local_source    # the DBIx::Class::ResultSource object for the source the rel is *from*
253           remote_source   # the DBIx::Class::ResultSource object for the source the rel is *to*
254           local_table     # the DBIx::Class::Schema::Loader::Table object for the table of the source the rel is from
255           local_cols      # an arrayref of column names of columns used in the rel in the source it is from
256           remote_table    # the DBIx::Class::Schema::Loader::Table object for the table of the source the rel is to
257           remote_cols     # an arrayref of column names of columns used in the rel in the source it is to
258           attrs           # the attributes that would be set
259
260       it should return the new hashref of attributes, or nothing for no
261       changes.
262
263       For example:
264
265           relationship_attrs => sub {
266               my %p = @_;
267
268               say "the relationship name is: $p{rel_name}";
269               say "the relationship is a: $p{rel_type}";
270               say "the local class is: ",  $p{local_source}->result_class;
271               say "the remote class is: ", $p{remote_source}->result_class;
272               say "the local table is: ", $p{local_table}->sql_name;
273               say "the rel columns in the local table are: ", (join ", ", @{$p{local_cols}});
274               say "the remote table is: ", $p{remote_table}->sql_name;
275               say "the rel columns in the remote table are: ", (join ", ", @{$p{remote_cols}});
276
277               if ($p{local_table} eq 'dogs' && @{$p{local_cols}} == 1 && $p{local_cols}[0] eq 'name') {
278                   $p{attrs}{could_be_snoopy} = 1;
279
280                   reutrn $p{attrs};
281               }
282           },
283
284       These are the default attributes:
285
286           has_many => {
287               cascade_delete => 0,
288               cascade_copy   => 0,
289           },
290           might_have => {
291               cascade_delete => 0,
292               cascade_copy   => 0,
293           },
294           belongs_to => {
295               on_delete => 'CASCADE',
296               on_update => 'CASCADE',
297               is_deferrable => 1,
298           },
299
300       For belongs_to relationships, these defaults are overridden by the
301       attributes introspected from the foreign key in the database, if this
302       information is available (and the driver is capable of retrieving it.)
303
304       This information overrides the defaults mentioned above, and is then
305       itself overridden by the user's "relationship_attrs" for "belongs_to"
306       if any are specified.
307
308       In general, for most databases, for a plain foreign key with no rules,
309       the values for a belongs_to relationship will be:
310
311           on_delete     => 'NO ACTION',
312           on_update     => 'NO ACTION',
313           is_deferrable => 0,
314
315       In the cases where an attribute is not supported by the DB, a value
316       matching the actual behavior is used, for example Oracle does not
317       support "ON UPDATE" rules, so "on_update" is set to "NO ACTION". This
318       is done so that the behavior of the schema is preserved when cross
319       deploying to a different RDBMS such as SQLite for testing.
320
321       In the cases where the DB does not support "DEFERRABLE" foreign keys,
322       the value is set to 1 if DBIx::Class has a working
323       "$storage->with_deferred_fk_checks". This is done so that the same
324       DBIx::Class code can be used, and cross deployed from and to such
325       databases.
326
327   debug
328       If set to true, each constructive DBIx::Class statement the loader
329       decides to execute will be "warn"-ed before execution.
330
331   db_schema
332       Set the name of the schema to load (schema in the sense that your
333       database vendor means it).
334
335       Can be set to an arrayref of schema names for multiple schemas, or the
336       special value "%" for all schemas.
337
338       For MSSQL, Sybase ASE, and Informix can be set to a hashref of
339       databases as keys and arrays of owners as values, set to the value:
340
341           { '%' => '%' }
342
343       for all owners in all databases.
344
345       Name clashes resulting from the same table name in different
346       databases/schemas will be resolved automatically by prefixing the
347       moniker with the database and/or schema.
348
349       To prefix/suffix all monikers with the database and/or schema, see
350       "moniker_parts".
351
352   moniker_parts
353       The database table names are represented by the
354       DBIx::Class::Schema::Loader::Table class in the loader, the
355       DBIx::Class::Schema::Loader::Table::Sybase class for Sybase ASE and
356       DBIx::Class::Schema::Loader::Table::Informix for Informix.
357
358       Monikers are created normally based on just the name property,
359       corresponding to the table name, but can consist of other parts of the
360       fully qualified name of the table.
361
362       The "moniker_parts" option is an arrayref of methods on the table class
363       corresponding to parts of the fully qualified table name, defaulting to
364       "['name']", in the order those parts are used to create the moniker
365       name.  The parts are joined together using "moniker_part_separator".
366
367       The 'name' entry must be present.
368
369       Below is a table of supported databases and possible "moniker_parts".
370
371       •   DB2, Firebird, mysql, Oracle, Pg, SQLAnywhere, SQLite, MS Access
372
373           "schema", "name"
374
375       •   Informix, MSSQL, Sybase ASE
376
377           "database", "schema", "name"
378
379   moniker_part_separator
380       String used to join "moniker_parts" when creating the moniker.
381       Defaults to the empty string. Use "::" to get a separate namespace per
382       database and/or schema.
383
384   constraint
385       Only load matching tables.
386
387       These can be specified either as a regex (preferably on the "qr//"
388       form), or as an arrayref of arrayrefs.  Regexes are matched against the
389       (unqualified) table name, while arrayrefs are matched according to
390       "moniker_parts".
391
392       For example:
393
394           db_schema => [qw(some_schema other_schema)],
395           moniker_parts => [qw(schema name)],
396           constraint => [
397               [ qr/\Asome_schema\z/ => qr/\A(?:foo|bar)\z/ ],
398               [ qr/\Aother_schema\z/ => qr/\Abaz\z/ ],
399           ],
400
401       In this case only the tables "foo" and "bar" in "some_schema" and "baz"
402       in "other_schema" will be dumped.
403
404   exclude
405       Exclude matching tables.
406
407       The tables to exclude are specified in the same way as for the
408       "constraint" option.
409
410   moniker_map
411       Overrides the default table name to moniker translation. Either
412
413       •   a nested hashref, which will be traversed according to
414           "moniker_parts"
415
416           For example:
417
418               moniker_parts => [qw(schema name)],
419               moniker_map => {
420                   foo => {
421                       bar  => "FooishBar",
422                   },
423               },
424
425           In which case the table "bar" in the "foo" schema would get the
426           moniker "FooishBar".
427
428       •   a hashref of unqualified table name keys and moniker values
429
430       •   a coderef that returns the moniker, which is called with the
431           following arguments:
432
433           •   the DBIx::Class::Schema::Loader::Table object for the table
434
435           •   the default moniker that DBIC would ordinarily give this table
436
437           •   a coderef that can be called with either of the hashref forms
438               to get the moniker mapped accordingly.  This is useful if you
439               need to handle some monikers specially, but want to use the
440               hashref form for the rest.
441
442       If the hash entry does not exist, or the function returns a false
443       value, the code falls back to default behavior for that table name.
444
445       The default behavior is to split on case transition and non-
446       alphanumeric boundaries, singularize the resulting phrase, then join
447       the titlecased words together. Examples:
448
449           Table Name       | Moniker Name
450           ---------------------------------
451           luser            | Luser
452           luser_group      | LuserGroup
453           luser-opts       | LuserOpt
454           stations_visited | StationVisited
455           routeChange      | RouteChange
456
457   moniker_part_map
458       Map for overriding the monikerization of individual "moniker_parts".
459       The keys are the moniker part to override, the value is either a
460       hashref or coderef for mapping the corresponding part of the moniker.
461       If a coderef is used, it gets called with the moniker part and the hash
462       key the code ref was found under.
463
464       For example:
465
466           moniker_part_map => {
467               schema => sub { ... },
468           },
469
470       Given the table "foo.bar", the code ref would be called with the
471       arguments "foo" and "schema", plus a coderef similar to the one
472       described in "moniker_map".
473
474       "moniker_map" takes precedence over this.
475
476   col_accessor_map
477       Same as moniker_map, but for column accessor names.  The nested hashref
478       form is traversed according to "moniker_parts", with an extra level at
479       the bottom for the column name.  If a coderef is passed, the code is
480       called with the following arguments:
481
482       •   the DBIx::Class::Schema::Loader::Column object for the column
483
484       •   the default accessor name that DBICSL would ordinarily give this
485           column
486
487       •   a hashref of this form:
488
489               {
490                   table_class     => name of the DBIC class we are building,
491                   table_moniker   => calculated moniker for this table (after moniker_map if present),
492                   table           => the DBIx::Class::Schema::Loader::Table object for the table,
493                   full_table_name => schema-qualified name of the database table (RDBMS specific),
494                   schema_class    => name of the schema class we are building,
495                   column_info     => hashref of column info (data_type, is_nullable, etc),
496               }
497
498       •   a coderef that can be called with a hashref map
499
500   rel_name_map
501       Similar in idea to moniker_map, but different in the details.  It can
502       be a hashref or a code ref.
503
504       If it is a hashref, keys can be either the default relationship name,
505       or the moniker. The keys that are the default relationship name should
506       map to the name you want to change the relationship to. Keys that are
507       monikers should map to hashes mapping relationship names to their
508       translation.  You can do both at once, and the more specific moniker
509       version will be picked up first.  So, for instance, you could have
510
511           {
512               bar => "baz",
513               Foo => {
514                   bar => "blat",
515               },
516           }
517
518       and relationships that would have been named "bar" will now be named
519       "baz" except that in the table whose moniker is "Foo" it will be named
520       "blat".
521
522       If it is a coderef, it will be passed a hashref of this form:
523
524           {
525               name           => default relationship name,
526               type           => the relationship type eg: C<has_many>,
527               local_class    => name of the DBIC class we are building,
528               local_moniker  => moniker of the DBIC class we are building,
529               local_columns  => columns in this table in the relationship,
530               remote_class   => name of the DBIC class we are related to,
531               remote_moniker => moniker of the DBIC class we are related to,
532               remote_columns => columns in the other table in the relationship,
533               # for type => "many_to_many" only:
534               link_class     => name of the DBIC class for the link table,
535               link_moniker   => moniker of the DBIC class for the link table,
536               link_rel_name  => name of the relationship to the link table,
537           }
538
539       In addition it is passed a coderef that can be called with a hashref
540       map.
541
542       DBICSL will try to use the value returned as the relationship name.
543
544   inflect_plural
545       Just like "moniker_map" above (can be hash/code-ref, falls back to
546       default if hash key does not exist or coderef returns false), but acts
547       as a map for pluralizing relationship names.  The default behavior is
548       to utilize "to_PL" in Lingua::EN::Inflect::Phrase.
549
550   inflect_singular
551       As "inflect_plural" above, but for singularizing relationship names.
552       Default behavior is to utilize "to_S" in Lingua::EN::Inflect::Phrase.
553
554   schema_base_class
555       Base class for your schema classes. Defaults to 'DBIx::Class::Schema'.
556
557   schema_components
558       List of components to load into the Schema class.
559
560   result_base_class
561       Base class for your table classes (aka result classes). Defaults to
562       'DBIx::Class::Core'.
563
564   additional_base_classes
565       List of additional base classes all of your table classes will use.
566
567   left_base_classes
568       List of additional base classes all of your table classes will use that
569       need to be leftmost.
570
571   additional_classes
572       List of additional classes which all of your table classes will use.
573
574   components
575       List of additional components to be loaded into all of your Result
576       classes.  A good example would be InflateColumn::DateTime
577
578   result_components_map
579       A hashref of moniker keys and component values.  Unlike "components",
580       which loads the given components into every Result class, this option
581       allows you to load certain components for specified Result classes. For
582       example:
583
584           result_components_map => {
585               StationVisited => '+YourApp::Schema::Component::StationVisited',
586               RouteChange    => [
587                                     '+YourApp::Schema::Component::RouteChange',
588                                     'InflateColumn::DateTime',
589                                 ],
590           }
591
592       You may use this in conjunction with "components".
593
594   result_roles
595       List of Moose roles to be applied to all of your Result classes.
596
597   result_roles_map
598       A hashref of moniker keys and role values.  Unlike "result_roles",
599       which applies the given roles to every Result class, this option allows
600       you to apply certain roles for specified Result classes. For example:
601
602           result_roles_map => {
603               StationVisited => [
604                                     'YourApp::Role::Building',
605                                     'YourApp::Role::Destination',
606                                 ],
607               RouteChange    => 'YourApp::Role::TripEvent',
608           }
609
610       You may use this in conjunction with "result_roles".
611
612   use_namespaces
613       This is now the default, to go back to "load_classes" in
614       DBIx::Class::Schema pass a 0.
615
616       Generate result class names suitable for "load_namespaces" in
617       DBIx::Class::Schema and call that instead of "load_classes" in
618       DBIx::Class::Schema. When using this option you can also specify any of
619       the options for "load_namespaces" (i.e. "result_namespace",
620       "resultset_namespace", "default_resultset_class"), and they will be
621       added to the call (and the generated result class names adjusted
622       appropriately).
623
624   dump_directory
625       The value of this option is a perl libdir pathname.  Within that
626       directory this module will create a baseline manual DBIx::Class::Schema
627       module set, based on what it creates at runtime.
628
629       The created schema class will have the same classname as the one on
630       which you are setting this option (and the ResultSource classes will be
631       based on this name as well).
632
633       Normally you wouldn't hard-code this setting in your schema class, as
634       it is meant for one-time manual usage.
635
636       See "dump_to_dir" in DBIx::Class::Schema::Loader for examples of the
637       recommended way to access this functionality.
638
639   dump_overwrite
640       Deprecated.  See "really_erase_my_files" below, which does *not* mean
641       the same thing as the old "dump_overwrite" setting from previous
642       releases.
643
644   really_erase_my_files
645       Default false.  If true, Loader will unconditionally delete any
646       existing files before creating the new ones from scratch when dumping a
647       schema to disk.
648
649       The default behavior is instead to only replace the top portion of the
650       file, up to and including the final stanza which contains "# DO NOT
651       MODIFY THE FIRST PART OF THIS FILE" leaving any customizations you
652       placed after that as they were.
653
654       When "really_erase_my_files" is not set, if the output file already
655       exists, but the aforementioned final stanza is not found, or the
656       checksum contained there does not match the generated contents, Loader
657       will croak and not touch the file.
658
659       You should really be using version control on your schema classes (and
660       all of the rest of your code for that matter).  Don't blame me if a bug
661       in this code wipes something out when it shouldn't have, you've been
662       warned.
663
664   overwrite_modifications
665       Default false.  If false, when updating existing files, Loader will
666       refuse to modify any Loader-generated code that has been modified since
667       its last run (as determined by the checksum Loader put in its comment
668       lines).
669
670       If true, Loader will discard any manual modifications that have been
671       made to Loader-generated code.
672
673       Again, you should be using version control on your schema classes.  Be
674       careful with this option.
675
676   omit_version
677       Omit the package version from the signature comment.
678
679   omit_timestamp
680       Omit the creation timestamp from the signature comment.
681
682   custom_column_info
683       Hook for adding extra attributes to the column_info for a column.
684
685       Must be a coderef that returns a hashref with the extra attributes.
686
687       Receives the DBIx::Class::Schema::Loader::Table object, column name and
688       column_info.
689
690       For example:
691
692           custom_column_info => sub {
693               my ($table, $column_name, $column_info) = @_;
694
695               if ($column_name eq 'dog' && $column_info->{default_value} eq 'snoopy') {
696                   return { is_snoopy => 1 };
697               }
698           },
699
700       This attribute can also be used to set "inflate_datetime" on a non-
701       datetime column so it also receives the "datetime_timezone" and/or
702       "datetime_locale".
703
704   datetime_timezone
705       Sets the timezone attribute for DBIx::Class::InflateColumn::DateTime
706       for all columns with the DATE/DATETIME/TIMESTAMP data_types.
707
708   datetime_locale
709       Sets the locale attribute for DBIx::Class::InflateColumn::DateTime for
710       all columns with the DATE/DATETIME/TIMESTAMP data_types.
711
712   datetime_undef_if_invalid
713       Pass a 0 for this option when using MySQL if you DON'T want
714       "datetime_undef_if_invalid => 1" in your column info for DATE, DATETIME
715       and TIMESTAMP columns.
716
717       The default is recommended to deal with data such as "00/00/00" which
718       sometimes ends up in such columns in MySQL.
719
720   config_file
721       File in Perl format, which should return a HASH reference, from which
722       to read loader options.
723
724   preserve_case
725       Normally database names are lowercased and split by underscore, use
726       this option if you have CamelCase database names.
727
728       Drivers for case sensitive databases like Sybase ASE or MSSQL with a
729       case-sensitive collation will turn this option on unconditionally.
730
731       NOTE: "naming" = "v8" is highly recommended with this option as the
732       semantics of this mode are much improved for CamelCase database names.
733
734       "naming" = "v7" or greater is required with this option.
735
736   qualify_objects
737       Set to true to prepend the "db_schema" to table names for
738       "__PACKAGE__->table" calls, and to some other things like Oracle
739       sequences.
740
741       This attribute is automatically set to true for multi db_schema
742       configurations, unless explicitly set to false by the user.
743
744   use_moose
745       Creates Schema and Result classes that use Moose, MooseX::NonMoose and
746       MooseX::MarkAsMethods (or namespace::autoclean, see below). The default
747       content after the md5 sum also makes the classes immutable.
748
749       It is safe to upgrade your existing Schema to this option.
750
751   only_autoclean
752       By default, we use MooseX::MarkAsMethods to remove imported functions
753       from your generated classes.  It uses namespace::autoclean to do this,
754       after telling your object's metaclass that any operator overloads in
755       your class are methods, which will cause namespace::autoclean to spare
756       them from removal.
757
758       This prevents the "Hey, where'd my overloads go?!" effect.
759
760       If you don't care about operator overloads (or if you know your Moose
761       is at at least version 2.1400, where MooseX::MarkAsMethods is no longer
762       necessary), enabling this option falls back to just using
763       namespace::autoclean itself.
764
765       If none of the above made any sense, or you don't have some pressing
766       need to only use namespace::autoclean, leaving this set to the default
767       is just fine.
768
769   col_collision_map
770       This option controls how accessors for column names which collide with
771       perl methods are named. See "COLUMN ACCESSOR COLLISIONS" for more
772       information.
773
774       This option takes either a single sprintf format or a hashref of
775       strings which are compiled to regular expressions that map to sprintf
776       formats.
777
778       Examples:
779
780           col_collision_map => 'column_%s'
781
782           col_collision_map => { '(.*)' => 'column_%s' }
783
784           col_collision_map => { '(foo).*(bar)' => 'column_%s_%s' }
785
786   rel_collision_map
787       Works just like "col_collision_map", but for relationship
788       names/accessors rather than column names/accessors.
789
790       The default is to just append "_rel" to the relationship name, see
791       "RELATIONSHIP NAME COLLISIONS".
792
793   uniq_to_primary
794       Automatically promotes the largest unique constraints with non-nullable
795       columns on tables to primary keys, assuming there is only one largest
796       unique constraint.
797
798   allow_extra_m2m_cols
799       Generate "many_to_many" relationship bridges even if the link table has
800       extra columns other than the foreign keys.  The primary key must still
801       equal the union of the foreign keys.
802
803   filter_generated_code
804       An optional hook that lets you filter the generated text for various
805       classes through a function that change it in any way that you want.
806       The function will receive the type of file, "schema" or "result", class
807       and code; and returns the new code to use instead.  For instance you
808       could add custom comments, or do anything else that you want.
809
810       The option can also be set to a string, which is then used as a filter
811       program, e.g. "perltidy".
812
813       If this exists but fails to return text matching "/\bpackage\b/", no
814       file will be generated.
815
816           filter_generated_code => sub {
817               my ($type, $class, $text) = @_;
818               ...
819               return $new_code;
820           }
821
822       You can also use this option to set perltidy markers in your generated
823       classes.  This will leave the generated code in the default format, but
824       will allow you to tidy your classes at any point in future, without
825       worrying about changing the portions of the file which are checksummed,
826       since "perltidy" will just ignore all text between the markers.
827
828           filter_generated_code => sub {
829               return "#<<<\n$_[2]\n#>>>";
830           }
831

METHODS

833       None of these methods are intended for direct invocation by regular
834       users of DBIx::Class::Schema::Loader. Some are proxied via
835       DBIx::Class::Schema::Loader.
836
837   new
838       Constructor for DBIx::Class::Schema::Loader::Base, used internally by
839       DBIx::Class::Schema::Loader.
840
841   load
842       Does the actual schema-construction work.
843
844   rescan
845       Arguments: schema
846
847       Rescan the database for changes. Returns a list of the newly added
848       table monikers.
849
850       The schema argument should be the schema class or object to be
851       affected.  It should probably be derived from the original schema_class
852       used during "load".
853
854   get_dump_filename
855       Arguments: class
856
857       Returns the full path to the file for a class that the class has been
858       or will be dumped to. This is a file in a temp dir for a dynamic
859       schema.
860
861   tables
862       Returns a sorted list of loaded tables, using the original database
863       table names.
864
865   monikers
866       Returns a hashref of loaded table to moniker mappings.  There will be
867       two entries for each table, the original name and the "normalized"
868       name, in the case that the two are different (such as databases that
869       like uppercase table names, or preserve your original mixed-case
870       definitions, or what-have-you).
871
872   classes
873       Returns a hashref of table to class mappings.  In some cases it will
874       contain multiple entries per table for the original and normalized
875       table names, as above in "monikers".
876
877   generated_classes
878       Returns an arrayref of classes that were actually generated (i.e. not
879       skipped because there were no changes).
880

NON-ENGLISH DATABASES

882       If you use the loader on a database with table and column names in a
883       language other than English, you will want to turn off the English
884       language specific heuristics.
885
886       To do so, use something like this in your loader options:
887
888           naming           => { monikers => 'v4' },
889           inflect_singular => sub { "$_[0]_rel" },
890           inflect_plural   => sub { "$_[0]_rel" },
891

COLUMN ACCESSOR COLLISIONS

893       Occasionally you may have a column name that collides with a perl
894       method, such as "can". In such cases, the default action is to set the
895       "accessor" of the column spec to "undef".
896
897       You can then name the accessor yourself by placing code such as the
898       following below the md5:
899
900           __PACKAGE__->add_column('+can' => { accessor => 'my_can' });
901
902       Another option is to use the "col_collision_map" option.
903

RELATIONSHIP NAME COLLISIONS

905       In very rare cases, you may get a collision between a generated
906       relationship name and a method in your Result class, for example if you
907       have a foreign key called "belongs_to".
908
909       This is a problem because relationship names are also relationship
910       accessor methods in DBIx::Class.
911
912       The default behavior is to append "_rel" to the relationship name and
913       print out a warning that refers to this text.
914
915       You can also control the renaming with the "rel_collision_map" option.
916

SEE ALSO

918       DBIx::Class::Schema::Loader, dbicdump
919

AUTHORS

921       See "AUTHORS" in DBIx::Class::Schema::Loader.
922

LICENSE

924       This library is free software; you can redistribute it and/or modify it
925       under the same terms as Perl itself.
926
927
928
929perl v5.36.0                      2023-01-2D0BIx::Class::Schema::Loader::Base(3)
Impressum