Class::DBI - Simple Database Abstraction
package Music::DBI; use base 'Class::DBI'; Music::DBI->set_db('Main', 'dbi:mysql', 'username', 'password'); package Artist; use base 'Music::DBI'; Artist->table('artist'); Artist->columns(All => qw/artistid name/); Artist->has_many('cds', 'CD' => artist); package CD; use base 'Music::DBI'; CD->table('cd'); CD->columns(All => qw/cdid artist title year/); CD->has_many('tracks', 'Track' => 'cd', { sort => 'position' }); CD->has_a(artist => 'CD::Artist'); CD->has_a(reldate => 'Time::Piece', inflate => sub { Time::Piece->strptime(shift => "%Y-%m-%d") }, deflate => 'ymd', } CD->might_have(liner_notes => LinerNotes => qw/notes/); package Track; use base 'Music::DBI'; Track->table('track'); Track->columns(All => qw/trackid cd position title/); #-- Meanwhile, in a nearby piece of code! --# my $artist = Artist->create({ artistid => 1, name => 'U2' }); my $cd = $artist->add_to_cds({ cdid => 1, title => 'October', year => 1980, }); # Oops, got it wrong. $cd->year(1981); $cd->update; # etc. while (my $track = $cd->tracks) { print $track->position, $track->title } $cd->delete; # also deletes the tracks my $cd = CD->retrieve(1); my @cds = CD->retrieve_all; my @cds = CD->search(year => 1980); my @cds = CD->search_like(title => 'October%');
Class::DBI provides a convenient abstraction layer to a database.
It not only provides a simple database to object mapping layer, but can be used to implement several higher order database functions (triggers, referential integrity, cascading delete etc.), at the application level, rather than at the database.
This is particularly useful when using a database which doesn't support these (such as MySQL), or when you would like your code to be portable across multiple databases which might implement these things in different ways.
In short, Class::DBI aims to make it simple to introduce 'best practice' when dealing with data stored in a relational database.
You must have an existing database set up, have DBI.pm installed and the necessary DBD:: driver module for that database. See DBI and the documentation of your particular database and driver for details.
Class::DBI works on a simple one class/one table model. It is your responsibility to have your database tables already set up. Automating that process is outside the scope of Class::DBI.
Using our CD example, you might declare a table something like this:
CREATE TABLE cd ( cdid INTEGER PRIMARY KEY, artist INTEGER, # references 'artist' title VARCHAR(255), year CHAR(4), );
It's usually wise to set up a "top level" class for your entire application to inherit from, rather than have each class inherit directly from Class::DBI. This gives you a convenient point to place system-wide overrides and enhancements to Class::DBI's behavior.
package Music::DBI; use base 'Class::DBI';
(It is prefered that you use base.pm to do this rather than setting @ISA, as your class may have to inherit some protected data fields).
Class::DBI needs to know how to access the database. It does this through a DBI connection which you set up by calling the set_db() method.
Music::DBI->set_db('Main', 'dbi:mysql', 'user', 'password');
By calling the method in your application base class all the table classes that inherit from it will share the same connection.
The first parameter is the name for this database connection and it must be 'Main' for Class::DBI to function. See "set_db" below and Ima::DBI for more details on set_db().
package CD; use base 'Music::DBI';
Each class will inherit from your application base class, so you don't need to repeat the information on how to connect to the database.
Inform Class::DBI what table you are using for this class:
CD->table('cd');
This is done using the columns() method. In the simplest form, you tell it the name of all your columns (primary key first):
CD->columns(All => qw/cdid artist title year/);
For more information about how you can more efficiently use subsets of your columns, "Lazy Population"
That's it! You now have a class with methods to create(), retrieve(), search() for, update() and delete() objects from your table, as well as accessors and mutators for each of the columns in that object (row).
Let's look at all that in more detail:
__PACKAGE__->set_db('Main', $data_source, $user, $password, \%attr);
For details on this method, Ima::DBI.
The special connection named 'Main' must always be set. Connections are inherited so it's usual to call set_db() just in your application base class.
package Music::DBI; use base 'Class::DBI'; Music::DBI->set_db('Main', 'dbi:foo:', 'user', 'password'); package My::Other::Table; use base 'Music::DBI';
Class::DBI helps you along a bit to set up the database connection. set_db() provides its own default attributes depending on the driver name in the data_source parameter. The most significant of which is AutoCommit. The DBI defaults AutoCommit on but Class::DBI will default it to off if the database driver is Oracle or Pg, so that transactions are used.
The set_db() method also provides defaults for these attributes:
FetchHashKeyName => 'NAME_lc', ShowErrorStatement => 1, AutoCommit => 1, ChopBlanks => 1,
The defaults can always be overridden by supplying your own \%attr parameter.
__PACKAGE__->table($table); $table = Class->table; $table = $obj->table;
An accessor to get/set the name of the database table in which this class is stored. It -must- be set.
Table information is inherited by subclasses, but can be overridden.
__PACKAGE__->sequence($sequence_name); $sequence_name = Class->sequence; $sequence_name = $obj->sequence;
If you are using a database which supports sequences, then you should declare this using the sequence() method.
__PACKAGE__->columns(Primary => 'id'); __PACKAGE__->sequence('class_id_seq');
Class::DBI will use the sequence to generate primary keys when objects are created yet the primary key is not specified.
If you are using a database with AUTO_INCREMENT (e.g. MySQL) then you do not need this, and a create() which does not specify a primary key will fill this in automagically.
The following are methods provided for convenience to create, retrieve and delete stored objects. It's not entirely one-size fits all and you might find it necessary to override them.
my $obj = Class->create(\%data);
This is a constructor to create a new object and store it in the database.
%data consists of the initial information to place in your object and the database. The keys of %data match up with the columns of your objects and the values are the initial settings of those fields.
my $cd = CD->create({ cdid => 1, artist => $artist, title => 'October', year => 1980, });
If the primary column is not in %data, create() will assume it is to be generated. If a sequence() has been specified for this Class, it will use that. Otherwise, it will assume the primary key can be generated by AUTO_INCREMENT and attempt to use that.
If the class has declared relationships with foreign classes via has_a(), you can pass an object to create() for the value of that key. Class::DBI will Do The Right Thing.
The before_create($self) trigger is invoked directly after storing the database values into the new object and before inserting the record into the database.
before_create
After the new record has been inserted into the database the data for non-primary key columns is discarded from the object. If those columns are accessed again they'll simply be fetched as needed. This ensures that the data in the application is consistant with what the database actually stored.
The after_create trigger is invoked after the database insert has executed and is passed ($self, discard_columns => \@discard_columns). The trigger code can modify the discard_columns array to affect which columns are discarded. For example:
after_create
Class->add_trigger(after_create => sub { my ($self, %args) = @_; my $discard_columns = $args{discard_columns}; # don't discard any columns, we trust that the # database will not have modified them. @$discard_columns = (); });
Take care to not discard a primary key column unless you know what you're doing.
my $cd = CD->find_or_create({ artist => 'U2', title => 'Boy' });
This checks if a CD can be found to match the information passed, and if not creates it.
$obj->delete; CD->delete(year => 1980, title => 'Greatest %');
Deletes this object from the database and from memory. If you have set up any relationships using has_many, this will delete the foreign elements also, recursively (cascading delete). $obj is no longer usable after this call.
If called as a class method, deletes all objects matching the search criteria given. Each object found will be deleted in turn, so cascading delete and other triggers will be honoured.
The before_delete trigger is when an object instance is about to be deleted. It is invoked before any cascaded deletes. The after_delete trigger is invoked after the record has been deleted from the database and just before the contents in memory are discarded.
before_delete
after_delete
We provide a few simple search methods, more to show the potential of the class than to be serious search methods.
$obj = Class->retrieve($id);
Given an ID it will retrieve the object with that ID from the database.
my $cd = CD->retrieve(1) or die "No such cd";
my @objs = Class->retrieve_all; my $iterator = Class->retrieve_all;
Retrieves objects for all rows in the database. This is probably a bad idea if your table is big, unless you use the iterator version.
@objs = Class->search(column1 => $value, column2 => $value ...);
This is a simple search for all objects where the columns specified are equal to the values specified e.g.:
@cds = CD->search(year => 1990); @cds = CD->search(title => "Greatest Hits", year => 1990);
@objs = Class->search_like(column1 => $like_pattern, ....);
This is a simple search for all objects where the columns specified are like the values specified. $like_pattern is a pattern given in SQL LIKE predicate syntax. '%' means "any one or more characters", '_' means "any single character".
@cds = CD->search_like(title => 'October%'); @cds = CD->search_like(title => 'Hits%', artist => 'Various%');
my $it = CD->search_like(title => 'October%'); while (my $cd = $it->next) { print $cd->title; }
Any of the above searches (including those defined by has_many) can also be used as an iterator. Rather than creating a list of objects matching your criteria, this will return a Class::DBI::Iterator instance, which can return the objects required one at a time.
Currently the iterator initially fetches all the matching row data into memory, and defers only the creation of the objects from that data until the iterator is asked for the next object. So using an iterator will only save significant memory if your objects inflate substantially on creation.
In the case of has_many relationships with a mapping method, the mapping method is not called until each time you call 'next'. This means that if your mapping is not a one-to-one, the results will probably not be what you expect.
CD->iterator_class('CD::Iterator');
You can also subclass the default iterator class to override its functionality. This is done via class data, and so is inherited into your subclasses.
my $obj = Class->construct(\%data);
This is a protected method and can only be called by subclasses.
It constructs a new object based solely on the %data given. It treats that data just like the columns of a table, where key is the column name, and value is the value in that column. This is very handy for cheaply setting up lots of objects from data for without going back to the database.
For example, instead of doing one SELECT to get a bunch of IDs and then feeding those individually to retrieve() (and thus doing more SELECT calls), you can do one SELECT to get the essential data of many objects and feed that data to construct():
return map $class->construct($_), $sth->fetchall_hash;
The construct() method creates a new empty object, loads in the column values, and then invokes the select trigger.
select
$new_obj = $obj->copy; $new_obj = $obj->copy($new_id); $new_obj = $obj->copy({ title => 'new_title', rating => 18 });
This creates a copy of the given $obj both in memory and in the database. The only difference is that the $new_obj will have a new primary identifier.
A new value for the primary key can be suppiled, otherwise the usual sequence or autoincremented primary key will be used. If you wish to change values other than the primary key, then pass a hashref of all the new values.
my $blrunner_dc = $blrunner->copy("Bladerunner: Director's Cut"); my $blrunner_unrated = $blrunner->copy({ Title => "Bladerunner: Director's Cut", Rating => 'Unrated', });
my $new_obj = Sub::Class->move($old_obj); my $new_obj = Sub::Class->move($old_obj, $new_id); my $new_obj = Sub::Class->move($old_obj, \%changes);
For transfering objects from one class to another. Similar to copy(), an instance of Sub::Class is created using the data in $old_obj (Sub::Class is a subclass of $old_obj's subclass). Like copy(), you can supply $new_id as the primary key of $new_obj (otherwise the usual sequence or autoincrement is used), or a hashref of multiple new values.
__PACKAGE__->add_trigger(trigger_point_name => \&code_to_execute); # e.g. __PACKAGE__->add_trigger(after_create => \&call_after_create);
It is possible to set up triggers that will be called at various points in the life of an object. Valid trigger points are:
before_create (also used for deflation) after_create before_set_$column (also used by add_constraint) after_set_$column (also used for inflation and by has_a) before_update (also used for deflation and by might_have) after_update before_delete after_delete select (also used for inflation and by construct and _flesh)
[Note: Trigger points 'create' and 'delete' are deprecated and will be removed in a future release.]
You can create any number of triggers for each point, but you cannot specify the order in which they will be run. Each will be passed the object being dealt with (whose values you may change if required), and return values will be ignored.
All triggers are passed the object they are being fired for. Some triggers are also passed extra parameters as name-value pairs. The individual triggers are documented with the methods that trigger them.
__PACKAGE__->add_constraint('name', column => \&check_sub); # e.g. __PACKAGE__->add_constraint('over18', age => \&check_age); # Simple version sub check_age { my ($value) = @_; return $value >= 18; } # Cross-field checking - must have SSN if age < 18 sub check_age { my ($value, $self, $column_name, $changing) = @_; return 1 if $value >= 18; # We're old enough. return 1 if $changing->{SSN}; # We're also being given an SSN return 0 if !ref($self); # This is a create, so we can't have an SSN return 1 if $self->ssn; # We already have one in the database return 0; # We can't find an SSN anywhere }
It is also possible to set up constraints on the values that can be set on a column. The constraint on a column is triggered whenever an object is created and whenever that column is modified.
The constraint code is called with four parameters:
- The new value to be assigned - The object it will be assigned to (or class name when initially creating an object) - The name of the column (useful if many constraints share the same code) - A hash ref of all new column values being assigned (useful for cross-field validation)
The constraints are applied to all the columns being set before the object data is updated. Attempting to create or update an object where one or more constraint fail results in an exception and the object remains unchanged.
Note 1: Constraints are implemented using before_set_$column triggers. This will only prevent you from setting these values through a the provided create() or set() methods. It will always be possible to bypass this if you try hard enough.
Note 2: When an object is created constraints are currently only checked for column names included in the parameters to create(). This is probably a bug and is likely to change in future.
Before an object is assigned data from the application (via create or a set accessor) the normalize_column_values() method is called with a reference to a hash containing the column names and the new values which are to be assigned (after any validation and constraint checking, as described below).
Currently Class::DBI does not offer any per-column mechanism here. The default method is empty. You can override it in your own classes to normalize (edit) the data in any way you need. For example the values in the hash for certain columns could be made lowercase.
The method is called as an instance method when the values of an existing object are being changed, and as a class (static) method when a new object is being created.
Before an object is assigned data from the application (via create or a set accessor) the validate_column_values() method is called with a reference to a hash containing the column names and the new values which are to be assigned.
The default method calls the before_set_$column trigger for each column name in the hash. Each trigger is called inside an eval. Any failures result in an exception after all have been checked. The exception data is a reference to a hash which holds the column name and error text for each trigger error.
When using this mechanism for form data validation, for example, this exception data can be stored in an exception object, via a custom _croak() method, and then caught and used to redisplay the form with error messages next to each field which failed validation.
All errors that are generated, or caught and propagated, by Class::DBI are handled by calling the _croak() method (as an instance method if possible, or else as a class method).
The _croak() method is passed an error message and in some cases some extra information as described below. The default behaviour is simply to call Carp::croak($message).
Applications that require custom behaviour should override the _croak() method in their application base class (or table classes for table-specific behaviour). For example:
use Error; sub _croak { my ($self, $message, %info) = @_; # convert errors into exception objects # except for duplicate insert errors which we'll ignore Error->throw(-text => $message, %info) unless $message =~ /^Can't insert .* duplicate/; return; }
The _croak() method is expected to trigger an exception and not return. If it does return then it should use return; so that an undef or empty list is returned as required depending on the calling context. You should only return other values if you are prepared to deal with the (unsupported) consequences.
return;
For exceptions that are caught and propagated by Class::DBI, $message includes the text of $@ and the original $@ value is available in $info{err}. That allows you to correctly propagate exception objects that may have been thrown 'below' Class::DBI (using Exception::Class::DBI for example).
Exceptions generated by some methods may provide additional data in $info{data} and, if so, also store the method name in $info{method}. For example, the validate_column_values() method stores details of failed validations in $info{data}. See individual method documentation for what additional data they may store, if any.
Note that Class::DBI doesn't go out of its way to catch and propagate fatal errors from the DBI or elsewhere. There are some parts of Class::DBI that invoke DBI calls without an eval { } wrapper. If the DBI detects an error then the default DBI RaiseError behaviour will trigger an exception that does not pass through the _croak() method.
All warnings are handled by calling the _carp() method (as an instance method if possible, or else as a class method). The default behaviour is simply to call Carp::carp().
Class::DBI inherits from Class::Accessor and thus provides individual accessor methods for every column in your subclass. It also overrides the get() and set() methods provided by Accessor to automagically handle database reading and writing.
$value = $obj->get($column_name); $obj->set($column_name, $value); $obj->set( %column_name_values );
These methods are the fundamental entry points for getting and seting column values. The extra accessor methods automatically generated for each column of your table are simple wrappers that call these get() and set() methods.
The set() method calls normalize_column_values() then validate_column_values() before storing the values. The before_set_$column trigger is invoked by validate_column_values(). The after_set_$column trigger is invoked after the new value has been stored.
before_set_$column
after_set_$column
It is possible for an object to not have all its column data in memory (due to lazy inflation). If the get() method is called for such a column then it will select the corresponding group of columns and then invoke the select trigger.
If you want to change the name of your accessors, you need to provide an accessor_name() method, which will convert a column name to a method name.
e.g: if your local naming convention was to prepend the word 'customer' to each column in the 'customer' table, so that you had the columns 'customerid', 'customername' and 'customerage', you would write:
sub accessor_name { my ($class, $column) = @_; $column =~ s/^customer//; return $column; }
Your methods would now be $customer->id, $customer->name and $customer->age rather than $customer->customerid etc.
Similarly, if you want to have distinct accessor and mutator methods, you would provide a mutator_name() method which would return the name of the method to change the value:
sub mutator_name { my ($class, $column) = @_; return "set_$column"; }
If you override the mutator_name, then the accessor method will be enforced as read-only, and the mutator as write-only.
There are two modes for the accessors to work in: manual update and autoupdate (This is sort of analagous to the manual vs autocommit in DBI). When in autoupdate mode, every time one calls an accessor to make a change an UPDATE will immediately be sent to the database. Otherwise, if autoupdate is off, no changes will be written until update() is explicitly called.
This is an example of manual updating:
# The calls to NumExplodingSheep() and Rating() will only make the # changes in memory, not in the database. Once update() is called # it writes to the database in one swell foop. $gone->NumExplodingSheep(5); $gone->Rating('NC-17'); $gone->update;
And of autoupdating:
# Turn autoupdating on for this object. $gone->autoupdate(1); # Each accessor call causes the new value to immediately be written. $gone->NumExplodingSheep(5); $gone->Rating('NC-17');
Manual updating is probably more efficient than autoupdating and it provides the extra safety of a discard_changes() option to clear out all unsaved changes. Autoupdating is more convient for the programmer.
If changes are left un-updated or not rolledback when the object is destroyed (falls out of scope or the program ends) then Class::DBI's DESTROY method will print a warning about unsaved changes.
__PACKAGE__->autoupdate($on_or_off); $update_style = Class->autoupdate; $obj->autoupdate($on_or_off); $update_style = $obj->autoupdate;
This is an accessor to the current style of auto-updating. When called with no arguments it returns the current auto-updating state, true for on, false for off. When given an argument it turns auto-updating on and off. A true value turns it on, a false one off. When called as a class method it will control the -pdating style for every instance of the class. When called on an individual object it will control updating for just that object, overriding the choice for the class.
__PACKAGE__->autoupdate(1); # Autoupdate is now on for the class. $obj = Class->retrieve('Aliens Cut My Hair'); $obj->autoupdate(0); # Shut off autoupdating for this object.
The update setting for an object is not stored in the database.
Autoupdating is off by default.
$obj->update;
If "autoupdate" is not enabled then changes you make to your object are not reflected in the database until you call update(). It is harmless to call update() if there are no changes to be saved. (If autoupdate is on there'll never be anything to save.)
Note: If you have transactions turned on (but see "TRANSACTIONS" below) you will also need to call dbi_commit(), as update() merely issues the UPDATE to the database).
After the database update has been executed, the data for columns that have been updated are deleted from the object. If those columns are accessed again they'll simply be fetched as needed. This ensures that the data in the application is consistant with what the database actually stored.
When update() is called the before_update($self) trigger is always invoked immediately.
before_update
If any columns have been updated then the after_update trigger is invoked after the database update has executed and is passed ($self, discard_columns => \@discard_columns). The trigger code can modify the discard_columns array to affect which columns are discarded. For example:
after_update
Class->add_trigger(after_update => sub { my ($self, %args) = @_; my $discard_columns = $args{discard_columns}; # discard the md5_hash column if any field starting with 'foo' # has been updated - because the md5_hash will have been changed # by a trigger. push @$discard_columns, 'md5_hash' if grep { /^foo/ } @$discard_columns; });
Take care to not delete a primary key column unless you know what you're doing.
$obj->discard_changes;
Removes any changes you've made to this object since the last update. Currently this simply discards the column values from the object.
If you're using autoupdate this method will throw an exception.
my $changed = $obj->is_changed; my @changed_keys = $obj->is_changed;
Indicates if the given $obj has changes since the last update. Returns a list of keys which have changed.
$id = $obj->id;
Returns a unique identifier for this object. It's the equivalent of $obj->get($self->columns('Primary'));
Class::DBI and its subclasses overload the perl builtin stringify and bool operators. This is a significant convienience.
When a Class::DBI object reference is used in a string context it will return the result of calling the id() method on itself.
This is especially useful for columns that have has_a() relationships. For example, consider a table that has price and currency fields:
package Widget; use base 'My::Class::DBI'; Widget->table('widget'); Widget->columns(All => qw/widgetid name price currency_code/); $obj = Widget->retrieve($id); print $obj->price . " " . $obj->currency_code;
The would print something like "42.07 USD". If the currency_code field is later changed to be a foreign key to a new currency table then $obj->currency_code will return an object reference instead of a plain string. Without overloading the stringify operator the example would now print something like "42.07 Widget=HASH(0x1275}" and the fix would be to change the code to add a call to id():
42.07 USD
42.07 Widget=HASH(0x1275}
print $obj->price . " " . $obj->currency_code->id;
However, with overloaded stringification, the original code continues to work as before, with no code changes needed.
This makes it much simpler and safer to add relationships to exisiting applications, or remove them later.
The perl builtin bool operator is also overloaded so that a Class::DBI object reference is always true unless the id() value is undefined. Thus an object with an id() of zero is not considered false.
Databases are all about relationships. And thus Class::DBI needs a way for you to set up descriptions of your relationhips.
Currently we provide three such methods: 'has_a', 'has_many', and 'might_have'.
CD->has_a(artist => 'CD::Artist'); print $cd->artist->name; CD->has_a(reldate => 'Date::Simple'); print $cd->reldate->format("%d %b, %Y"); CD->has_a(reldate => 'Time::Piece', inflate => sub { Time::Piece->strptime(shift => "%Y-%m-%d") }, deflate => 'ymd', } print $cd->reldate->strftime("%d %b, %Y");
We use 'has_a' to declare that the value we have stored in the column is a reference to something else. Thus, when we access the 'artist' method we don't just want that ID returned, but instead we inflate it to this other object.
This might be another Class::DBI representation, in which case we will call retrieve() on that class, or it can be any other object which is either instantiated with new(), or by a given 'inflate' method, and which can be 'deflated' either by stringification (such as Date::Simple), or by the given 'deflate' method.
CD->has_many('tracks', CD::Track => 'cd'); my @tracks = $cd->tracks; my $track6 = $cd->add_to_tracks({ position => 6, title => 'Tomorrow', });
We use 'has_many' to declare that someone else is storing our primary key in their table, and create a method which returns a list of all the associated objects, and another method to create a new associated object.
In the above example we say that the table of the CD::Track class contains our primary key in its 'cd' column, and that we wish to access all the occasions of that (i.e. the tracks on this cd) through the 'tracks' method.
We also create an 'add_to_tracks' method that adds a track to a given CD. In this example this call is exactly equivalent to calling:
my $track6 = CD::Track->create({ cd => $cd->id, position => 6, title => 'Tomorrow', });
Artist->has_many(cds => 'CD'); my @cds = $artist->cds(year => 1980);
When calling the has_many method, you can also supply any additional key/value pairs for restricting the search. The above example will only return the CDs with a year of 1980.
CD->has_many('tracks', 'Track' => 'cd', { sort => 'playorder' });
Often you wish to order the values returned from has_many. This can be done by passing a hash ref containing a 'sort' value of the column by wish you want to order.
CD->has_many('styles', [ 'StyleRef' => 'style' ], 'cd');
For many-to-many relationships, where we have a lookup table, we can avoid having to set up a helper method to convert our list of cross-references into the objects we really want, by adding the mapping method to our foreign class declaration.
The above is exactly equivalent to:
CD->has_many('_style_refs', 'StyleRef', 'cd'); sub styles { my $self = shift; return map $_->style, $self->_style_refs; }
CD->might_have(method_name => Class => (@fields_to_import)); CD->might_have(liner_notes => LinerNotes => qw/notes/); my $liner_notes_object = $cd->liner_notes; my $notes = $cd->notes; # equivalent to $cd->liner_notes->notes;
might_have() is similar to has_many() for relationships that can have at most one associated objects. For example, if you have a CD database to which you want to add liner notes information, you might not want to add a 'liner_notes' column to your main CD table even though there is no multiplicity of relationship involved (each CD has at most one 'liner notes' field). So, we create another table with the same primary key as this one, with which we can cross-reference.
But you don't want to have to keep writing methods to turn the the 'list' of liner_notes objects you'd get back from has_many into the single object you'd need. So, might_have() does this work for you. It creates you an accessor to fetch the single object back if it exists, and it also allows you import any of its methods into your namespace. So, in the example above, the LinerNotes class can be mostly invisible - you can just call $cd->notes and it will call the notes method on the correct LinerNotes object transparently for you.
Making sure you don't have namespace clashes is up to you, as is correctly creating the objects, but I may make these simpler in later versions. (Particularly if someone asks for them!)
If none of these do exactly what you want, and you have more complex many-to-many relationships, you may find Class::DBI::Join (available on CPAN) to be useful.
has_a(), might_have() and has_many() check that the relevant class already exists. If it doesn't then they try to load a module of the same name using require. If the require fails because it can't find the module then it will assume it's not a simple require (i.e., Foreign::Class isn't in Foreign/Class.pm) and that you will care of it and ignore the warning. Any other error, such as a syntax error, triggers an exception.
NOTE: The two classes in a relationship do not have to be in the same database, on the same machine, or even in the same type of database! It is quite acceptable for a table in a MySQL database to be connected to a different table in an Oracle database, and for cascading delete etc to work across these. This should assist greatly if you need to migrate a database gradually.
There are several main methods for setting up your own SQL queries:
For queries which could be used to create a list of matching objects you can create a constructor method associated with this SQL and let Class::DBI do the work for you, or just inline the entire query.
For more complex queries you need to fall back on the underlying Ima::DBI query mechanism.
__PACKAGE__->add_constructor(method_name => 'SQL_where_clause');
The SQL can be of arbitrary complexity and will be turned into: SELECT (essential columns) FROM (table name) WHERE <your SQL>
This will then create a method of the name you specify, which returns a list of objects as with any built in query.
For example:
CD->add_constructor(new_music => 'year > 2000'); my @recent = CD->new_music;
You can also supply placeholders in your SQL, which must then be specified at query time:
CD->add_constructor(new_music => 'year > ?'); my @recent = CD->new_music(2000);
my @cds = CD->retrieve_from_sql(qq{ artist = 'Ozzy Osbourne' AND title like "%Crazy" AND year <= 1986 ORDER BY year LIMIT 2,3 });
On occassions where you want to execute arbitrary SQL, but don't want to go to the trouble of setting up a constructor method, you can inline the entire WHERE clause, and just get the objects back directly.
When you can't use 'add_constructor', e.g. when using aggregate functions, you can fall back on the fact that Class::DBI inherits from Ima::DBI and prefers to use its style of dealing with statemtents, via set_sql().
So, to add a query that returns the 10 Artists with the most CDs, you could write (with MySQL):
Artist->set_sql(most_cds => qq{ SELECT artist.id, COUNT(cd.id) AS cds FROM artist, cd WHERE artist.id = cd.artist GROUP BY artist.id ORDER BY cds DESC LIMIT 10 });
This will automatically set up the method Artist->search_most_cds(), which executes this search and returns the relevant objects (or Iterator).
If you have placeholders in your query, you must pass the relevant arguments when calling your search method.
This does the equivalent of:
sub top_ten { my $class = shift; my $sth = $class->sql_most_cds; $sth->execute; return $class->sth_to_objects($sth); }
The $sth which we use to return the objects here is a normal DBI-style statement handle, so if your results can't even be turned into objects easily, you can still call $sth->fetchrow_array etc and return whatever data you choose.
If you want to write new methods which are inheritable by your subclasses you must be careful not to hardcode any information about your class's table name or primary key, and instead use the table() and columns() methods instead.
my @music = CD::Music->search_where( artist => [ 'Ozzy', 'Kelly' ], status => { '!=', 'outdated' }, );
The Class::DBI::AbstractSearch module, available from CPAN, is a plugin for Class::DBI that allows you to write arbitrarily complex searches using perl data structures, rather than SQL.
In the tradition of Perl, Class::DBI is lazy about how it loads your objects. Often, you find yourself using only a small number of the available columns and it would be a waste of memory to load all of them just to get at two, especially if you're dealing with large numbers of objects simultaneously.
You should therefore group together your columns by typical usage, as fetching one value from a group can also pre-fetch all the others in that group for you, for more efficient access.
So for example, if we usually fetch the artist and title, but don't use the 'year' so much, then we could say the following:
CD->columns(Primary => 'cdid'); CD->columns(Essential => qw/artist title/); CD->columns(Others => qw/year runlength/);
Now when you fetch back a CD it will come pre-loaded with the 'artist' and 'title' fields. Fetching the 'year' will mean another visit to the database, but will bring back the 'runlength' whilst it's there. This can potentially increase performance.
If you don't like this behavior, then just add all your columns to the 'All' group, and Class::DBI will load everything at once.
CD->columns(TEMP => qw/nonpersistent/);
If you wish to have fields that act like columns in every other way, but that don't actually exist in the database (and thus will not persist), you can declare them as part of a column group of 'TEMP'.
my @all_columns = $class->columns; my @columns = $class->columns($group); my $primary = $class->primary_column; my @essential = $class->_essential;
There are three 'reserved' groups. 'All', 'Essential' and 'Primary'.
'All' are all columns used by the class. If not set it will be created from all the other groups.
'Primary' is the single primary key column for this class. It must be set before objects can be used. (Multiple primary keys are not supported). If 'All' is given but not 'Primary' it will assume the first column in 'All' is the primary key.
'Essential' are the minimal set of columns needed to load and use the object. Only the columns in this group will be loaded when an object is retrieve()'d. It is typically used to save memory on a class that has a lot of columns but where we mostly only use a few of them. It will automatically be set to 'All' if you don't set it yourself. The 'Primary' column is always part of your 'Essential' group and Class::DBI will put it there if you don't.
For simplicity we provide private 'primary_column' and '_essential' methods which return these.
Class->has_column($column); $obj->has_column($column);
This will return true if the given $column is a column of the class or object.
SQL is largely case insensitive. Perl is largely not. This can lead to problems when reading information out of a database. Class::DBI does some data normalization, and provides you some methods for doing likewise.
$obj->normalize(\@columns);
There is no guarantee how a database will muck with the case of columns, so to protect against things like DBI->fetchrow_hashref() returning strangely cased column names (along with table names appended to the front) we normalize all column names before using them as data keys.
$obj->normalize_hash(\%hash);
Given a %hash, it will normalize all its keys using normalize(). This is for convenience.
In general Class::DBI prefers auto-commit to be turned on in your database, as there are several problems inherent in operating in a transactional environment with Class::DBI. In particular:
Your database handles are shared with possibly many other totally unrelated classes. This means if you commit one class's handle you might actually be committing another class's transaction as well.
A single class might have many database handles. Even worse, if you're working with a subclass it might have handles you're not aware of!
However, as long as you are aware of these caveats, and try to keep the scope of your transactions small, preferably down to the scope of a single method, you should be able to work with transactions with few problems.
A nice idiom for this (courtesy of Dominic Mitchell) is:
sub do_transaction { my $class = shift; my ( $code ) = @_; # Turn off AutoCommit for this scope. # A commit will occur at the exit of this block automatically, # when the local AutoCommit goes out of scope. local $class->db_Main->{ AutoCommit }; # Execute the required code inside the transaction. eval { $code->() }; if ( $@ ) { my $commit_error = $@; eval { $class->dbi_rollback }; # might also die! die $commit_error; } } And then you just call: Music::DBI->do_transaction( sub { my $artist = Artist->create({ name => 'Pink Floyd' }); my $cd = $artist->add_to_cds({ title => 'Dark Side Of The Moon', year => 1974, }); });
Now either both will get added, or the entire transaction will be rolled back.
The preferred method of interacting with Class::DBI is for you to write a subclass for your database connection, with each table-class inheriting in turn from it.
As well as encapsulating the connection information in one place, this also allows you to override default behaviour or add additional functionality across all of your classes.
As the innards of Class::DBI are still in flux, you must exercise extreme caution in overriding private methods of Class::DBI (those starting with an underscore), unless they are explicitly mentioned in this documentation as being safe to override. If you find yourself needing to do this, then I would suggest that you ask on the mailing list about it, and we'll see if we can either come up with a better approach, or provide a new means to do whatever you need to do.
Composite primary keys are not yet supported.
Altering the primary key column currently causes Bad Things to happen. I should really protect against this.
I plan to include a 'Cookbook' of typical tricks and tips. Please send me your suggestions.
Theoretically this should work with almost any standard RDBMS. Of course, in the real world, we know that that's not true. We know that this works with MySQL, PostgrSQL and SQLite, each of which have their own additional subclass on CPAN that you may with to explore if you're using any of these.
L<Class::DBI::mysql>, L<Class::DBI::Pg>, L<Class::DBI::SQLite>
For the most part it's been reported to work with Oracle and Sybase. Beyond that lies The Great Unknown(tm). If you have access to other databases, please give this a test run, and let me know the results.
This is known not to work with DBD::RAM
Tony Bowden <classdbi@tmtm.com>
Michael G Schwern <schwern@pobox.com>
Tim Bunce, Tatsuhiko Miyagawa, Damian Conway, Uri Gutman, Mike Lambert and the POOP group....
Support for Class::DBI is via the mailing list. The list is used for general queries on the use of Class::DBI, bug reports, patches, and suggestions for improvements or new features.
To join the list visit http://groups.kasei.com/mail/info/cdbi-talk
The interface to Class::DBI is fairly stable, but there are still occassions when we need to break backwards compatability. Such issues will be raised on the list before release, so if you use Class::DBI in a production environment, it's probably a good idea to keep a watch on the list.
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
http://poop.sourceforge.net/ provides a document comparing a variety of different approaches to database persistence, such as Class::DBI, Alazabo, Tangram, SPOPS etc.
CPAN contains a variety of other modules that can be used with Class::DBI: Class::DBI::Join, Class::DBI::FromCGI, Class::DBI::AbstractSearch etc.
For a full list see: http://search.cpan.org/search?query=Class%3A%3ADBI
Class::DBI is built on top of Ima::DBI, Class::Accessor and Class::Data::Inheritable.
To install Class::DBI::__::Base, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Class::DBI::__::Base
CPAN shell
perl -MCPAN -e shell install Class::DBI::__::Base
For more information on module installation, please visit the detailed CPAN module installation guide.