NAME¶
DBIx::DBSchema - Database-independent schema objects
SYNOPSIS¶
use DBIx::DBSchema;
$schema = new DBIx::DBSchema @dbix_dbschema_table_objects;
$schema = new_odbc DBIx::DBSchema $dbh;
$schema = new_odbc DBIx::DBSchema $dsn, $user, $pass;
$schema = new_native DBIx::DBSchema $dbh;
$schema = new_native DBIx::DBSchema $dsn, $user, $pass;
$schema->save("filename");
$schema = load DBIx::DBSchema "filename" or die $DBIx::DBSchema::errstr;
$schema->addtable($dbix_dbschema_table_object);
@table_names = $schema->tables;
$DBIx_DBSchema_table_object = $schema->table("table_name");
@sql = $schema->sql($dbh);
@sql = $schema->sql($dsn, $username, $password);
@sql = $schema->sql($dsn); #doesn't connect to database - less reliable
$perl_code = $schema->pretty_print;
%hash = eval $perl_code;
use DBI qw(:sql_types); $schema = pretty_read DBIx::DBSchema \%hash;
DESCRIPTION¶
DBIx::DBSchema objects are collections of DBIx::DBSchema::Table objects and
represent a database schema.
This module implements an OO-interface to database schemas. Using this module,
you can create a database schema with an OO Perl interface. You can read the
schema from an existing database. You can save the schema to disk and restore
it in a different process. You can write SQL CREATE statements statements for
different databases from a single source. In recent versions, you can
transform one schema to another, adding any necessary new columns and tables
(and, as of 0.33, indices).
Currently supported databases are MySQL, PostgreSQL and SQLite. Sybase and
Oracle drivers are partially implemented. DBIx::DBSchema will attempt to use
generic SQL syntax for other databases. Assistance adding support for other
databases is welcomed. See DBIx::DBSchema::DBD, "Driver Writer's Guide
and Base Class".
METHODS¶
- new TABLE_OBJECT, TABLE_OBJECT, ...
- Creates a new DBIx::DBSchema object.
- new_odbc DATABASE_HANDLE | DATA_SOURCE USERNAME PASSWORD [
ATTR ]
- Creates a new DBIx::DBSchema object from an existing data
source, which can be specified by passing an open DBI database handle, or
by passing the DBI data source name, username, and password. This uses the
experimental DBI type_info method to create a schema with standard (ODBC)
SQL column types that most closely correspond to any non-portable column
types. Use this to import a schema that you wish to use with many
different database engines. Although primary key and (unique) index
information will only be read from databases with DBIx::DBSchema::DBD
drivers (currently MySQL and PostgreSQL), import of column names and
attributes *should* work for any database. Note that this method only uses
"ODBC" column types; it does not require or use an ODBC
driver.
- new_native DATABASE_HANDLE | DATA_SOURCE USERNAME PASSWORD
[ ATTR ]
- Creates a new DBIx::DBSchema object from an existing data
source, which can be specified by passing an open DBI database handle, or
by passing the DBI data source name, username and password. This uses
database-native methods to read the schema, and will preserve any
non-portable column types. The method is only available if there is a
DBIx::DBSchema::DBD for the corresponding database engine (currently,
MySQL and PostgreSQL).
- load FILENAME
- Loads a DBIx::DBSchema object from a file. If there is an
error, returns false and puts an error message in
$DBIx::DBSchema::errstr;
- save FILENAME
- Saves a DBIx::DBSchema object to a file.
- addtable TABLE_OBJECT
- Adds the given DBIx::DBSchema::Table object to this
DBIx::DBSchema.
- tables
- Returns a list of the names of all tables.
- table TABLENAME
- Returns the specified DBIx::DBSchema::Table object.
- sql [ DATABASE_HANDLE | DATA_SOURCE [ USERNAME PASSWORD [
ATTR ] ] ]
- Returns a list of SQL `CREATE' statements for this schema.
The data source can be specified by passing an open DBI database handle, or
by passing the DBI data source name, username and password.
Although the username and password are optional, it is best to call this
method with a database handle or data source including a valid username
and password - a DBI connection will be opened and used to check the
database version as well as for more reliable quoting and type mapping.
Note that the database connection will be used passively, not to
actually run the CREATE statements.
If passed a DBI data source (or handle) such as `DBI:mysql:database' or
`DBI:Pg:dbname=database', will use syntax specific to that database
engine. Currently supported databases are MySQL and PostgreSQL.
If not passed a data source (or handle), or if there is no driver for the
specified database, will attempt to use generic SQL syntax.
- sql_update_schema [ OPTIONS_HASHREF, ] PROTOTYPE_SCHEMA [
DATABASE_HANDLE | DATA_SOURCE [ USERNAME PASSWORD [ ATTR ] ] ]
- Returns a list of SQL statements to update this schema so
that it is idential to the provided prototype schema, also a
DBIx::DBSchema object.
Right now this method knows how to add new tables and alter existing tables,
including indices. If specifically requested by passing an options hashref
with drop_tables set true before all other arguments, it will also
drop tables.
See "sql_alter_table" in DBIx::DBSchema::Table,
"sql_add_column" in DBIx::DBSchema::Column and
"sql_alter_column" in DBIx::DBSchema::Column for additional
specifics and limitations.
The data source can be specified by passing an open DBI database handle, or
by passing the DBI data source name, username and password.
Although the username and password are optional, it is best to call this
method with a database handle or data source including a valid username
and password - a DBI connection will be opened and used to check the
database version as well as for more reliable quoting and type mapping.
Note that the database connection will be used passively, not to
actually run the CREATE statements.
If passed a DBI data source (or handle) such as `DBI:mysql:database' or
`DBI:Pg:dbname=database', will use syntax specific to that database
engine. Currently supported databases are MySQL and PostgreSQL.
If not passed a data source (or handle), or if there is no driver for the
specified database, will attempt to use generic SQL syntax.
- update_schema [ OPTIONS_HASHREF, ] PROTOTYPE_SCHEMA,
DATABASE_HANDLE | DATA_SOURCE [ USERNAME PASSWORD [ ATTR ] ]
- Same as sql_update_schema, except actually runs the SQL
commands to update the schema. Throws a fatal error if any statement
fails.
- pretty_print
- Returns the data in this schema as Perl source, suitable
for assigning to a hash.
- pretty_read HASHREF
- This method is not recommended. If you need to load
and save your schema to a file, see the /load and /save methods.
Creates a schema as specified by a data structure such as that created by
pretty_print method.
AUTHORS¶
Ivan Kohler <ivan-dbix-dbschema@420.am>
Charles Shapiro <charles.shapiro@numethods.com> and Mitchell Friedman
<mitchell.friedman@numethods.com> contributed the start of a Sybase
driver.
Daniel Hanks <hanksdc@about-inc.com> contributed the Oracle driver.
Jesse Vincent contributed the SQLite driver and fixes to quiet down internal
usage of the old API.
Slaven Rezic <srezic@cpan.org> contributed column and table dropping, Pg
bugfixes and more.
CONTRIBUTIONS¶
Contributions are welcome! I'm especially keen on any interest in the top
items/projects below under BUGS.
COPYRIGHT¶
Copyright (c) 2000-2007 Ivan Kohler Copyright (c) 2000 Mail Abuse Prevention
System LLC Copyright (c) 2007-2010 Freeside Internet Services, Inc. All rights
reserved. This program is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
BUGS AND TODO¶
Multiple primary keys are not yet supported.
Foreign keys and other constraints are not yet supported.
sql_update_schema doesn't deal with deleted columns yet.
Need to port and test with additional databases
Each DBIx::DBSchema object should have a name which corresponds to its name
within the SQL database engine (DBI data source).
pretty_print is actually pretty ugly.
pretty_print isn't so good about quoting values... save/load is a much better
alternative to using pretty_print/pretty_read
pretty_read is pretty ugly too.
pretty_read should *not* create and pass in old-style unique/index indices when
nothing is given in the read.
Perhaps pretty_read should eval column types so that we can use DBI
qw(:sql_types) here instead of externally.
Need to support "using" index attribute in pretty_read and in reverse
engineering
perhaps we should just get rid of pretty_read entirely. pretty_print is useful
for debugging, but pretty_read is pretty bunk.
sql CREATE TABLE output should convert integers (i.e. use DBI qw(:sql_types);)
to local types using DBI->type_info plus a hash to fudge things
SEE ALSO¶
DBIx::DBSchema::Table, DBIx::DBSchema::Index, DBIx::DBSchema::Column,
DBIx::DBSchema::DBD, DBIx::DBSchema::DBD::mysql, DBIx::DBSchema::DBD::Pg,
FS::Record, DBI
POD ERRORS¶
Hey!
The above document had some coding errors, which are explained
below:
- Around line 429:
- =cut found outside a pod block. Skipping to next
block.