DBIx::Class::Schema::Loader::Base man page on Fedora

Man page or keyword search:  
man Server   31170 pages
apropos Keyword Search (all sections)
Output format
Fedora logo
[printable version]

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::EM::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".)

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

       For example:

	 relationship_attrs => {
	   belongs_to => { is_deferrable => 0 },
	 },

       use this to turn off DEFERRABLE on your foreign key constraints.

   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 'name' entry must be present.

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

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

	   "schema", "name"

       ·   Informix, MSSQL, Sybase ASE

	   "database", "schema", "name"

   constraint
       Only load tables matching regex.	 Best specified as a qr// regex.

   exclude
       Exclude tables matching regex.  Best specified as a qr// regex.

   moniker_map
       Overrides the default table name to moniker translation.	 Can be either
       a hashref of table keys and moniker values, or a coderef for a
       translator function taking a table object argument (which stringifies
       to the unqualified table name) and returning a scalar moniker.  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

   col_accessor_map
       Same as moniker_map, but for column accessor names.  If a coderef is
       passed, the code is called with arguments of

	  the name of the column in the underlying database,
	  default accessor name that DBICSL would ordinarily give this column,
	  {
	     table_class     => name of the DBIC class we are building,
	     table_moniker   => calculated moniker for this table (after moniker_map if present),
	     table	     => table object of interface DBIx::Class::Schema::Loader::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),
	  }

       the table object stringifies to the unqualified table name.

   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, the argument passed will be 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,
	   }

       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.

   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 table object (which stringifies to the unqualified table
       name), 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.

   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.

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

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.

BASE CLASS: $base_class
   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".

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

AUTHOR
       See "AUTHOR" in DBIx::Class::Schema::Loader and "CONTRIBUTORS" 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.14.2			  2012-05-DBIx::Class::Schema::Loader::Base(3)
[top]

List of man pages available for Fedora

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net