if (-d $main) {
$dir = catfile($main, $prefix, join q(-), @{$versions})
} else {
- croak "$main does not exist; please write/generate some SQL";
+ if ($self->ignore_ddl) {
+ return []
+ } else {
+ croak "$main does not exist; please write/generate some SQL"
+ }
}
my %files;
=head1 DIRECTORY LAYOUT
-Arguably this is the best feature of L<DBIx::Class::DeploymentHandler>. It's
-heavily based upon L<DBIx::Migration::Directories>, but has some extensions and
-modifications, so even if you are familiar with it, please read this. I feel
-like the best way to describe the layout is with the following example:
+Arguably this is the best feature of L<DBIx::Class::DeploymentHandler>.
+It's spiritually based upon L<DBIx::Migration::Directories>, but has a
+lot of extensions and modifications, so even if you are familiar with it,
+please read this. I feel like the best way to describe the layout is with
+the following example:
$sql_migration_dir
|- _source
C<$sql_migration_dir/_common/upgrade/1-2/002-generate-customers.pl>.
C<.pl> files don't have to be in the C<_common> directory, but most of the time
-they should be, because perl scripts are generally be database independent.
+they should be, because perl scripts are generally database independent.
Note that unlike most steps in the process, C<preinstall> will not run SQL, as
there may not even be an database at preinstall time. It will run perl scripts
=over 2
+=item C<deploy> This directory merely contains directories named after schema
+versions, which in turn contain C<yaml> files that are serialized versions
+of the schema at that version. These files are not for editing by hand.
+
+=back
+
+=item C<_preprocess_schema> This directory can contain the following
+directories:
+
+=over 2
+
=item C<downgrade> This directory merely contains directories named after
migrations, which are of the form C<$from_version-$to_version>. Inside of
these directories you may put Perl scripts which are to return a subref
that takes the arguments C<< $from_schema, $to_schema >>, which are
L<SQL::Translator::Schema> objects.
-=item C<deploy> This directory merely contains directories named after schema
-versions, which in turn contain C<yaml> files that are serialized versions
-of the schema at that version. These files are not for editing by hand.
-
=back
=item C<$storage_type> This is a set of scripts that gets run depending on what
})
}
+=attr ignore_ddl
+
+This attribute will, when set to true (default is false), cause the DM to use
+L<SQL::Translator> to use the C<_source>'s serialized SQL::Translator::Schema
+instead of any pregenerated SQL. If you have a development server this is
+probably the best plan of action as you will not be putting as many generated
+files in your version control. Goes well with with C<databases> of C<[]>.
+
=attr schema
The L<DBIx::Class::Schema> (B<required>) that is used to talk to the database
The version the schema on your harddrive is at. Defaults to
C<< $self->schema->schema_version >>.
-
-=begin comment
-
-=head2 __ddl_consume_with_prefix
-
- $dm->__ddl_consume_with_prefix( 'SQLite', [qw( 1.00 1.01 )], 'upgrade' )
-
-This is the meat of the multi-file upgrade/deploy stuff. It returns a list of
-files in the order that they should be run for a generic "type" of upgrade.
-You should not be calling this in user code.
-
-=head2 _ddl_schema_consume_filenames
-
- $dm->__ddl_schema_consume_filenames( 'SQLite', [qw( 1.00 )] )
-
-Just a curried L</__ddl_consume_with_prefix>. Get's a list of files for an
-initial deploy.
-
-=head2 _ddl_schema_produce_filename
-
- $dm->__ddl_schema_produce_filename( 'SQLite', [qw( 1.00 )] )
-
-Returns a single file in which an initial schema will be stored.
-
-=head2 _ddl_schema_up_consume_filenames
-
- $dm->_ddl_schema_up_consume_filenames( 'SQLite', [qw( 1.00 )] )
-
-Just a curried L</__ddl_consume_with_prefix>. Get's a list of files for an
-upgrade.
-
-=head2 _ddl_schema_down_consume_filenames
-
- $dm->_ddl_schema_down_consume_filenames( 'SQLite', [qw( 1.00 )] )
-
-Just a curried L</__ddl_consume_with_prefix>. Get's a list of files for a
-downgrade.
-
-=head2 _ddl_schema_up_produce_filenames
-
- $dm->_ddl_schema_up_produce_filename( 'SQLite', [qw( 1.00 1.01 )] )
-
-Returns a single file in which the sql to upgrade from one schema to another
-will be stored.
-
-=head2 _ddl_schema_down_produce_filename
-
- $dm->_ddl_schema_down_produce_filename( 'SQLite', [qw( 1.00 1.01 )] )
-
-Returns a single file in which the sql to downgrade from one schema to another
-will be stored.
-
-=head2 _resultsource_install_filename
-
- my $filename_fn = $dm->_resultsource_install_filename('User');
- $dm->$filename_fn('SQLite', '1.00')
-
-Returns a function which in turn returns a single filename used to install a
-single resultsource. Weird interface is convenient for me. Deal with it.
-
-=head2 _run_sql_and_perl
-
- $dm->_run_sql_and_perl([qw( list of filenames )])
-
-Simply put, this runs the list of files passed to it. If the file ends in
-C<.sql> it runs it as sql and if it ends in C<.pl> it runs it as a perl file.
-
-Depending on L</txn_wrap> all of the files run will be wrapped in a single
-transaction.
-
-=head2 _prepare_install
-
- $dm->_prepare_install({ add_drop_table => 0 }, sub { 'file_to_create' })
-
-Generates the sql file for installing the database. First arg is simply
-L<SQL::Translator> args and the second is a coderef that returns the filename
-to store the sql in.
-
-=head2 _prepare_changegrade
-
- $dm->_prepare_changegrade('1.00', '1.01', [qw( 1.00 1.01)], 'upgrade')
-
-Generates the sql file for migrating from one schema version to another. First
-arg is the version to start from, second is the version to go to, third is the
-L<version set|DBIx::Class::DeploymentHandler/VERSION SET>, and last is the
-direction of the changegrade, be it 'upgrade' or 'downgrade'.
-
-=head2 _read_sql_file
-
- $dm->_read_sql_file('foo.sql')
-
-Reads a sql file and returns lines in an C<ArrayRef>. Strips out comments,
-transactions, and blank lines.
-
-=end comment
projects / dbsrgits/DBIx-Class-DeploymentHandler.git / blobdiff