Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
DBIx::Class::Schema::LUserrContributed PerDBIx::Class::Schema::Loader::Base(3)

NAME
       DBIx::Class::Schema::Loader::Base - Base	DBIx::Class::Schema::Loader
       Implementation.

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

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

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

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

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

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

       Specifying

	   naming => 'current'

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

       The option also takes a hashref:

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

       or

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

       The keys	are:

       ALL Set "relationships",	"monikers" and "column_accessors" to the
	   specified value.

       relationships
	   How to name relationship accessors.

       monikers
	   How to name Result classes.

       column_accessors
	   How to name column accessors	in Result classes.

       force_ascii
	   For "v8" mode and later, uses String::ToIdentifier::EN instead of
	   String::ToIdentifier::EN::Unicode to	force monikers and other
	   identifiers to ASCII.

       The values can be:

       current
	   Latest style, whatever that happens to be.

       v4  Unsingularlized monikers, "has_many"	only relationships with	no _id
	   stripping.

       v5  Monikers singularized as whole words, "might_have" relationships
	   for FKs on "UNIQUE" constraints, "_id" stripping for	belongs_to
	   relationships.

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

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

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

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

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

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

       v8  (EXPERIMENTAL)

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

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

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

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

       preserve
	   For "monikers", this	option does not	inflect	the table names	but
	   makes monikers based	on the actual name. For	"column_accessors"
	   this	option does not	normalize CamelCase column names to lowercase
	   column accessors, but makes accessors that are the same names as
	   the columns (with any non-\w	chars replaced with underscores.)

       singular
	   For "monikers", singularizes	the names using	the most current
	   inflector. This is the same as setting the option to	"current".

       plural
	   For "monikers", pluralizes the names, using the most	current
	   inflector.

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

	   __PACKAGE__->naming('current');

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

	   __PACKAGE__->naming('v7');

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

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

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

       Comment metadata	can be stored in two ways.

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

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

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

       Set this	to 0 to	turn off all POD generation.

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

       name
	   Use "NAME" section only.

       description
	   Force "DESCRIPTION" always.

       auto
	   Use "DESCRIPTION" if	length > "pod_comment_spillover_length", this
	   is the default.

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

       The default is 60

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

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

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

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

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

       For example:

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

       use this	to turn	DBIx::Class cascades 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
       If set to true, each constructive DBIx::Class statement the loader
       decides to execute will be "warn"-ed before execution.

   db_schema
       Set the name of the schema to load (schema in the sense that your
       database	vendor means it).

       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
       The database table names	are represented	by the
       DBIx::Class::Schema::Loader::Table class	in the loader, the
       DBIx::Class::Schema::Loader::Table::Sybase class	for Sybase ASE and
       DBIx::Class::Schema::Loader::Table::Informix for	Informix.

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

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

	   "schema", "name"

       o   Informix, MSSQL, Sybase ASE

	   "database", "schema", "name"

   moniker_part_separator
       String used to join "moniker_parts" when	creating the moniker.
       Defaults	to the empty string. Use "::" to get a separate	namespace per
       database	and/or schema.

   constraint
       Only load matching tables.

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

       For example:

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

       In this case only the tables "foo" and "bar" in "some_schema" and "baz"
       in "other_schema" will be dumped.

   exclude
       Exclude matching	tables.

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

   moniker_map
       Overrides the default table name	to moniker translation.	Either

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

       o   a hashref of	unqualified table name keys and	moniker	values

       o   a coderef that returns the moniker, which is	called with the
	   following arguments:

	   o   the DBIx::Class::Schema::Loader::Table object for the table

	   o   the default moniker that	DBIC would ordinarily give this	table

	   o   a coderef that can be called with either	of the hashref forms
	       to get the moniker mapped accordingly.  This is useful if you
	       need to handle some monikers specially, but want	to use the
	       hashref form for	the rest.

       If the hash entry does not exist, or the	function returns a false
       value, the code falls back to default behavior for that table name.

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

       For example:

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

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

       "moniker_map" takes precedence over this.

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

       o   the DBIx::Class::Schema::Loader::Column object for the column

       o   the default accessor	name that DBICSL would ordinarily give this
	   column

       o   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),
	       }

       o   a coderef that can be called	with a hashref map

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

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

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

       and relationships that would have been named "bar" will now be named
       "baz" except that in the	table whose moniker is "Foo" it	will be	named
       "blat".

       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
       Just like "moniker_map" above (can be hash/code-ref, falls back to
       default if hash key does	not exist or coderef returns false), but acts
       as a map	for pluralizing	relationship names.  The default behavior is
       to utilize "to_PL" in Lingua::EN::Inflect::Phrase.

   inflect_singular
       As "inflect_plural" above, but for singularizing	relationship names.
       Default behavior	is to utilize "to_S" in	Lingua::EN::Inflect::Phrase.

   schema_base_class
       Base class for your schema classes. Defaults to 'DBIx::Class::Schema'.

   schema_components
       List of components to load into the Schema class.

   result_base_class
       Base class for your table classes (aka result classes). Defaults	to
       'DBIx::Class::Core'.

   additional_base_classes
       List of additional base classes all of your table classes will use.

   left_base_classes
       List of additional base classes all of your table classes will use that
       need to be leftmost.

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

   components
       List of additional components to	be loaded into all of your Result
       classes.	 A good	example	would be InflateColumn::DateTime

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

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

       You may use this	in conjunction with "components".

   result_roles
       List of Moose roles to be applied to all	of your	Result classes.

   result_roles_map
       A hashref of moniker keys and role values.  Unlike "result_roles",
       which applies the given roles to	every Result class, this option	allows
       you to apply certain roles for specified	Result classes.	For example:

	   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
       This is now the default,	to go back to "load_classes" in
       DBIx::Class::Schema pass	a 0.

       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 value of this option	is a perl libdir pathname.  Within that
       directory this module will create a baseline manual DBIx::Class::Schema
       module set, based on what it creates at runtime.

       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
       Deprecated.  See	"really_erase_my_files"	below, which does *not*	mean
       the same	thing as the old "dump_overwrite" setting from previous
       releases.

   really_erase_my_files
       Default false.  If true,	Loader will unconditionally delete any
       existing	files before creating the new ones from	scratch	when dumping a
       schema to disk.

       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
       Default false.  If false, when updating existing	files, Loader will
       refuse to modify	any Loader-generated code that has been	modified since
       its last	run (as	determined by the checksum Loader put in its comment
       lines).

       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 the	package	version	from the signature comment.

   omit_timestamp
       Omit the	creation timestamp from	the signature comment.

   custom_column_info
       Hook for	adding extra attributes	to the column_info for a column.

       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
       Sets the	timezone attribute for DBIx::Class::InflateColumn::DateTime
       for all columns with the	DATE/DATETIME/TIMESTAMP	data_types.

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

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

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

   config_file
       File in Perl format, which should return	a HASH reference, from which
       to read loader options.

   preserve_case
       Normally	database names are lowercased and split	by underscore, use
       this option if you have CamelCase database names.

       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
       Set to true to prepend the "db_schema" to table names for
       "__PACKAGE__->table" calls, and to some other things like Oracle
       sequences.

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

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

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

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

       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 controls how	accessors for column names which collide with
       perl methods are	named. See "COLUMN ACCESSOR COLLISIONS"	for more
       information.

       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
       Works just like "col_collision_map", but	for relationship
       names/accessors rather than column names/accessors.

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

   uniq_to_primary
       Automatically promotes the largest unique constraints with non-nullable
       columns on tables to primary keys, assuming there is only one largest
       unique constraint.

   allow_extra_m2m_cols
       Generate	"many_to_many" relationship bridges even if the	link table has
       extra columns other than	the foreign keys.  The primary key must	still
       equal the union of the foreign keys.

   filter_generated_code
       An optional hook	that lets you filter the generated text	for various
       classes through a function that change it in any	way that you want.
       The function will receive the type of file, "schema" or "result", class
       and code; and returns the new code to use instead.  For instance	you
       could add custom	comments, or do	anything else that you want.

       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#>>>";
	   }

METHODS
       None of these methods are intended for direct invocation	by regular
       users of	DBIx::Class::Schema::Loader. Some are proxied via
       DBIx::Class::Schema::Loader.

   new
       Constructor for DBIx::Class::Schema::Loader::Base, used internally by
       DBIx::Class::Schema::Loader.

   load
       Does the	actual schema-construction work.

   rescan
       Arguments: schema

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

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

   get_dump_filename
       Arguments: class

       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
       Returns a sorted	list of	loaded tables, using the original database
       table names.

   monikers
       Returns a hashref of loaded table to moniker mappings.  There will be
       two entries for each table, the original	name and the "normalized"
       name, in	the case that the two are different (such as databases that
       like uppercase table names, or preserve your original mixed-case
       definitions, or what-have-you).

   classes
       Returns a hashref of table to class mappings.  In some cases it will
       contain multiple	entries	per table for the original and normalized
       table names, as above in	"monikers".

   generated_classes
       Returns an arrayref of classes that were	actually generated (i.e. not
       skipped because there were no changes).

NON-ENGLISH DATABASES
       If you use the loader on	a database with	table and column names in a
       language	other than English, you	will want to turn off the English
       language	specific heuristics.

       To do so, use something like this in your loader	options:

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

COLUMN ACCESSOR	COLLISIONS
       Occasionally you	may have a column name that collides with a perl
       method, such as "can". In such cases, the default action	is to set the
       "accessor" of the column	spec to	"undef".

       You can then name the accessor yourself by placing code such as the
       following below the md5:

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

       Another option is to use	the "col_collision_map"	option.

RELATIONSHIP NAME COLLISIONS
       In very rare cases, you may get a collision between a generated
       relationship name and a method in your Result class, for	example	if you
       have a foreign key called "belongs_to".

       This is a problem because relationship names are	also relationship
       accessor	methods	in DBIx::Class.

       The default behavior is to append "_rel"	to the relationship name and
       print out a warning that	refers to this text.

       You can also control the	renaming with the "rel_collision_map" option.

SEE ALSO
       DBIx::Class::Schema::Loader, dbicdump

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

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

perl v5.32.1			  2018-03-DBIx::Class::Schema::Loader::Base(3)

NAME | SYNOPSIS | DESCRIPTION | CONSTRUCTOR OPTIONS | METHODS | NON-ENGLISH DATABASES | COLUMN ACCESSOR COLLISIONS | RELATIONSHIP NAME COLLISIONS | SEE ALSO | AUTHORS | LICENSE

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=DBIx::Class::Schema::Loader::Base&sektion=3&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help