1DBIx::Class::Schema::LoUasdeerr:C:oBnatsrei(b3u)ted PerlDBDIoxc:u:mCelnatsast:i:oSnchema::Loader::Base(3)
2
3
4
6 DBIx::Class::Schema::Loader::Base - Base DBIx::Class::Schema::Loader
7 Implementation.
8
10 See DBIx::Class::Schema::Loader.
11
13 This is the base class for the storage-specific
14 "DBIx::Class::Schema::*" classes, and implements the common
15 functionality between them.
16
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
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
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
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
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
918 DBIx::Class::Schema::Loader, dbicdump
919
921 See "AUTHORS" in DBIx::Class::Schema::Loader.
922
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)