NAME
DBIx::Class::DeploymentHandler::DeployMethod::SQL::Translator
VERSION
version 0.001000_01
DESCRIPTION
This class is the meat of DBIx::Class::DeploymentHandler. It takes care of generating sql files representing schemata as well as sql files to move from one version of a schema to the rest. One of the hallmark features of this class is that it allows for multiple sql files for deploy and upgrade, allowing developers to fine tune deployment. In addition it also allows for perl files to be run at any stage of the process.
For basic usage see DBIx::Class::DeploymentHandler::HandlesDeploy. What's documented here is extra fun stuff or private methods.
ATTRIBUTES
schema
The DBIx::Class::Schema (required) that is used to talk to the database and generate the DDL.
storage
The DBIx::Class::Storage that is actually used to talk to the database and generate the DDL. This is automatically created with "_build_storage".
sqltargs
#rename
upgrade_directory
The directory (default 'sql') that upgrades are stored in
databases
The types of databases (default [qw( MySQL SQLite PostgreSQL )]) to generate files for
txn_wrap
Set to true (which is the default) to wrap all upgrades and deploys in a single transaction.
METHODS
__ddl_consume_with_prefix
$dm->__ddl_consume_with_prefix( 'SQLite', [qw( 1.00 1.01 )], 'up' )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.
_ddl_schema_consume_filenames
$dm->__ddl_schema_consume_filenames( 'SQLite', [qw( 1.00 )] )Just a curried "__ddl_consume_with_prefix". Get's a list of files for an initial deploy.
_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.
_ddl_schema_up_consume_filenames
$dm->_ddl_schema_up_consume_filenames( 'SQLite', [qw( 1.00 )] )Just a curried "__ddl_consume_with_prefix". Get's a list of files for an upgrade.
_ddl_schema_down_consume_filenames
$dm->_ddl_schema_down_consume_filenames( 'SQLite', [qw( 1.00 )] )Just a curried "__ddl_consume_with_prefix". Get's a list of files for a downgrade.
_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.
_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.
_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.
_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 .sql it runs it as sql and if it ends in .pl it runs it as a perl file.
Depending on "txn_wrap" all of the files run will be wrapped in a single transaction.
_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 SQL::Translator args and the second is a coderef that returns the filename to store the sql in.
_prepare_changegrade
$dm->_prepare_changegrade('1.00', '1.01', [qw( 1.00 1.01)], 'up')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 version set, and last is the direction of the changegrade, be it 'up' or 'down'.
_read_sql_file
$dm->_read_sql_file('foo.sql')Reads a sql file and returns lines in an ArrayRef. Strips out comments, transactions, and blank lines.
DIRECTORY LAYOUT
Arguably this is the best feature of DBIx::Class::DeploymentHandler. It's heavily based upon 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:
$sql_migration_dir
|- SQLite
| |- down
| | `- 1-2
| | `- 001-auto.sql
| |- schema
| | `- 1
| | `- 001-auto.sql
| `- up
| |- 1-2
| | `- 001-auto.sql
| `- 2-3
| `- 001-auto.sql
|- _common
| |- down
| | `- 1-2
| | `- 002-remove-customers.pl
| `- up
| `- 1-2
| `- 002-generate-customers.pl
|- _generic
| |- down
| | `- 1-2
| | `- 001-auto.sql
| |- schema
| | `- 1
| | `- 001-auto.sql
| `- up
| `- 1-2
| |- 001-auto.sql
| `- 002-create-stored-procedures.sql
`- MySQL
|- down
| `- 1-2
| `- 001-auto.sql
|- schema
| `- 1
| `- 001-auto.sql
`- up
`- 1-2
`- 001-auto.sqlSo basically, the code
$dm->deploy(1)on an SQLite database that would simply run $sql_migration_dir/SQLite/schema/1/001-auto.sql. Next,
$dm->upgrade_single_step([1,2])would run $sql_migration_dir/SQLite/up/1-2/001-auto.sql followed by $sql_migration_dir/_common/up/1-2/002-generate-customers.pl.
Now, a .pl file doesn't have to be in the _common directory, but most of the time it probably should be, since perl scripts will mostly be database independent.
_generic exists for when you for some reason are sure that your SQL is generic enough to run on all databases. Good luck with that one.
PERL SCRIPTS
A perl script for this tool is very simple. It merely needs to contain a sub called run that takes a DBIx::Class::Schema as it's only argument. A very basic perl script might look like:
#!perl
use strict;
use warnings;
sub run {
my $schema = shift;
$schema->resultset('Users')->create({
name => 'root',
password => 'root',
})
}AUTHOR
Arthur Axel "fREW" Schmidt <frioux+cpan@gmail.com>COPYRIGHT AND LICENSE
This software is copyright (c) 2010 by Arthur Axel "fREW" Schmidt.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.