NAME
DBIx::DataModel::Doc::Delta_v2 - Differences introduced in version 2.0
DESCRIPTION
The architecture and Application Programming Interface (API) of DBIx::DataModel were deeply refactored in version 2.0. This document enumerates the main differences introduced in that version. For older changes, see also DBIx::DataModel::Doc::Delta_v1.
NEW META LAYER
All information about the schema is stored within meta-objects; such objects can be queried for retrieving the list of tables, the list of associations, etc.
SCHEMA MODES
The $dbh database connection, and various parameters about SQL generation, are no longer stored within the Schema class; instead, they are stored in instances of DBIx::DataModel::Schema. By default, there is only one such instance, and the class has a singleton() method for reaching it : this is called single-schema mode, which is compatible with previous versions of DBIx::DataModel, and is also the most economical way to work with the database.
Even in single-schema mode, it is possible to switch between several $dbh, through methods "localize_state" in DBIx::DataModel::Schema and "do_transaction" in DBIx::DataModel::Schema. However, there is of course only one connected $dbh at any point in time.
If the application needs to communicate with several $dbh at the same time, then it is necessary to enter multi-schema mode, simply by explicitly calling the "new" in DBIx::DataModel::Schema method on the schema subclass :
my $schema1 = My::DB->new(dbh => $dbh1);
my $schema2 = My::DB->new(dbh => $dbh2);As soon as the new() method is called, the system knows that it should work in multi-schema mode, and the singleton() method becomes prohibited. As a consequence, calls to fetch() or select() can no longer be invoked on a class name: the schema needs to be specified
# this does NOT work in multi-schema mode
my $rows = My::DB::SomeTable->select(...)
# but this does work
my $rows = $schema1->table('SomeTable')->select(...)Another consequence of multi-schema mode is that every data row will contain a reference to its schema, under name __schema. This is necessary if we want to be able to follow paths from that row :
my $other_row = $row->some_associated_table();Therefore there is a small penalty for multi-schema mode, because the __schema in every row needs some memory and some bookkeeping.
API CHANGES
Deprecation of camelCase methods
All methods and parameters previously written in "camelCase" notation (à la Java, i.e "someMethodNameWithManyWords") are now written with underscores (à la Perl, i.e. "some_method_name_with_many_words").
SQL::Abstract::More
Code that used to be with DBIx_:DataModel, for extending the SQL::Abstract API, and tuning SQL generation, is now moved to a separate distribution called SQL::Abstract::More.
Introduction of Params::Validate
Arguments to methods are now systematically checked through Params::Validate. This is in accordance with the principle of "defensive programming", and helps to discover errors sooner.
Extended usage for update() and delete()
It is now possible to perform bulk updates or deletes, just like in straigt SQL :
My::DB::SomeTable->update(-set => {foo => 123}
-where => {bar => {"<" => 456}});
My::DB::SomeTable->delete(-where => {col => {-like => "foobar%"});Table inheritance
If your database supports table inheritance (like for example PostgreSQL), you might define a corresponding inheritance structure between the Perl table classes.
Reorganization of data sources
The former class DBIx::DataModel::View is deprecated; it is now treated exactly like a Table.
A new DBIx::DataModel::Source::Join class has been introduced (together with its meta DBIx::DataModel::Meta::Source::Join) : this gives a cleaner structure for the specific needs of database joins.
DEPRECATED FEATURES
Autoload
Autoload is deprecated. Reading or setting a column value is done through the usual Perl operations for working with hashrefs.