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->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 = CD->create({ cdid => 1, artist => $artist, title => 'October', year => 1980, }); # Oops, got it wrong. $cd->year(1981); $cd->commit; # 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.

How to set it up
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 for details. Class::DBI works on a simple one class/one table model. It is your responsibility to have your database 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 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. package CD; use base 'Class::DBI'; Class::DBI needs to know how to access the database. It does this through a DBI connection which you set up. Set up is by calling the set_db() method and declaring a database connection named 'Main'. (Note that this connection MUST be called 'Main', and so Class::DBI will actually ignore this argument and pass 'Main' up to Ima::DBi anyhow). CD->set_db('Main', 'dbi:mysql', 'user', 'password'); We also set up some default attributes depending on the type of database we're dealing with: For instance, if MySQL is detected, AutoCommit will be turned on, whereas under Oracle, ChopBlanks is turned on. The defaults can be extended or overriden by passing your own $attr hashref as the 5th argument. [See Ima::DBI for more details on set_db()] 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 declare your columns, "Lazy Population" That's it! You now have a class with methods to create(), retrieve(), copy(), move(), search() for 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:

set_db
__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. It's often wise to set up a "top level" class for your entire application to inherit from, rather than directly from Class::DBI. This gives you a convenient point to place system-wide overrides and enhancements to Class::DBI's behavior. It also lets you set the Main connection in one place rather than scattering the connection info all over the code. package My::Class::DBI; use base 'Class::DBI'; __PACKAGE__->set_db('Main', 'dbi:foo', 'user', 'password'); package My::Other::Thing; use base 'My::Class::DBI'; Class::DBI helps you along a bit to set up the database connection. set_db() normally provides its own default attributes on a per database basis. For instance, if MySQL is detected, AutoCommit will be turned on. Under Oracle, ChopBlanks is turned on. As more databases are tested, more defaults will be added. The defaults can always be overridden by supplying your own %attr.

table
__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.

sequence
__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.

create
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 hasa(), it can pass an object to create() for the value of that key. Class::DBI will Do The Right Thing.

delete
$obj->delete; 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. We provide a few simple search methods, more to show the potential of the class than to be serious search methods.

retrieve
$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";

retrieve_all
my @objs = Class->retrieve_all; my $iterator = Class->retrieve_all; my @all_cds = CD->retrieve_all; while (my $cd = CD->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.

search
@objs = Class->search($key, $value); @objs = $obj->search($key, $value); This is a simple search through the stored objects for all objects whose $key has the given $value. @cds = CD->search(year => 1990);

search_like
@objs = Class->search_like($key, $like_pattern); @objs = $obj->search_like($key, $like_pattern); A simple search for objects whose $key matches the $like_pattern given. $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%'); 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. This should help considerably with memory when accessing a large number of search results.

QUICK RETRIEVAL
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;

copy
$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 suppiler, 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', });

move
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(before_create => \&call_before_create); __PACKAGE__->add_trigger(after_create => \&call_after_create); __PACKAGE__->add_trigger(before_delete => \&call_before_delete); __PACKAGE__->add_trigger(after_delete => \&call_after_delete); __PACKAGE__->add_trigger(before_update => \&call_before_update); __PACKAGE__->add_trigger(after_update => \&call_after_update); __PACKAGE__->add_trigger(select => \&call_after_select); It is possible to set up triggers that will be called immediately after a SELECT, or either side of a DELETE, UPDATE or CREATE. 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. __PACKAGE__->add_constraint('name', column => \&check_sub); # e.g. __PACKAGE__->add_constraint('over18', age => \&check_age); sub check_age { my $value = shift; return $value >= 18; } It is also possible to set up constraints on the values that can be set on a column. Attempting to create a object where this constraint fails, or to update the value of an existing object with an invalid value, will result in an error. Note 1: 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.

accessors
Class::DBI inherits from Class::Accessor and thus provides accessor methods for every column in your subclass. It overrides the get() and set() methods provided by Accessor to automagically handle database writing.

changing your accessor names
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.

manual vs auto commit
There are two modes for the accessors to work in. Manual commit and autocommit. This is sort of analagous to the manual vs autocommit in DBI, but is not implemented in terms of this. What it simply means is this... when in autocommit mode every time one calls an accessor to make a change the change will immediately be written to the database. Otherwise, if autocommit is off, no changes will be written until commit() is explicitly called. This is an example of manual committing: # The calls to NumExplodingSheep() and Rating() will only make the # changes in memory, not in the database. Once commit() is called # it writes to the database in one swell foop. $gone->NumExplodingSheep(5); $gone->Rating('NC-17'); $gone->commit; And of autocommitting: # Turn autocommitting on for this object. $gone->autocommit(1); # Each accessor call causes the new value to immediately be written. $gone->NumExplodingSheep(5); $gone->Rating('NC-17'); Manual committing is probably more efficient than autocommiting and it provides the extra safety of a rollback() option to clear out all unsaved changes. Autocommitting is more convient for the programmer. If changes are left uncommitted 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.

autocommit
__PACKAGE__->autocommit($on_or_off); $commit_style = Class->autocommit; $obj->autocommit($on_or_off); $commit_style = $obj->autocommit; This is an accessor to the current style of autocommitting. When called with no arguments it returns the current autocommitting state, true for on, false for off. When given an argument it turns autocommiting on and off. A true value turns it on, a false one off. When called as a class method it will control the committing style for every instance of the class. When called on an individual object it will control committing for just that object, overriding the choice for the class. __PACKAGE__->autocommit(1); # Autocommit is now on for the class. $obj = Class->retrieve('Aliens Cut My Hair'); $obj->autocommit(0); # Shut off autocommitting for this object. The commit setting for an object is not stored in the database. Autocommitting is off by default. NOTE This has nothing to do with DBI's AutoCommit attribute.

commit
$obj->commit; Writes any changes you've made via accessors to disk. There's nothing wrong with using commit() when autocommit is on, it'll just silently do nothing.

rollback
$obj->rollback; Removes any changes you've made to this object since the last commit. Currently this simply reloads the values from the database. This can have concurrency issues. If you're using autocommit this method will throw an exception.

is_changed
my $changed = $obj->is_changed; my @changed_keys = $obj->is_changed; Indicates if the given $obj has uncommitted changes. Returns a list of keys which have changed.

id
$id = $obj->id; Returns a unique identifier for this object. It's the equivalent of $obj->get($self->columns('Primary')); 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: 'hasa', 'has_many', and 'might_have'.

hasa
CD->hasa(CD::Artist => 'artist'); print $cd->artist->name; We use 'hasa' to declare that we are storing someone else's primary key in our table. Thus, when we access the 'artist' method we don't just want that ID returned, but the CD::Artist to which it corresponds.

has_many
CD->has_many('tracks', CD::Track => 'cd'); my @tracks = $cd->tracks; 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. 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. This also declares the reciprocal 'hasa' relationship on CD::Track->cd. Ordering 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.

might_have
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!)

Notes
hasa(), might_have() and has_many() will try to require the relevant foreign class for you. If the require fails, it will assume it's not a simple require (ie. Foreign::Class isn't in Foreign/Class.pm) and that you've already taken care of it and ignore the warning. 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 two main methods for setting up your own SQL queries. If you are writing a simple SELECT, then you can set up a 'filter' for this, and let Class::DBI do the bulk of the work for you. For more complex queries you need to fall back on the underlyin Ima::DBI query mechanism.

make_filter
__PACKAGE__->make_filter(method_name => 'SQL_where_clause'); This allows you to set up simple filters (searches). It will create a method, named after the first parameter, which will execute a SELECT based on the restriction passed, which should be a valid SQL 'WHERE' clause. CD->make_filter(new_music => 'year > 2000'); my @recent = CD->new_music; You can replace the hard-coded value with a '?' to allow for changing this at run-time: CD->make_filter(new_music => 'year > ?'); my @recent = CD->new_music(2000); You can also replace the hard-coded column name with a sprintf-style %s to allow for multiple queries with the same underlying syntax: CD->make_filter(greater_than => '%s > ?'); sub new_music { shift->greater_than(year => 2000) } my @recent = CD->new_music(2000);

Ima::DBI queries
When you can't use a 'filter' to create your query, 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(). (Now is a good time to skim Ima::DBI.) In order 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. 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.

columns
my @all_columns = $class->columns; my @columns = $class->columns($group); my $primary = $class->_primary; 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' and '_essential' methods which return these.

has_column
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.

normalize
$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.

normalize_hash
$obj->normalize_hash(\%hash); Given a %hash, it will normalize all its keys using normalize(). This is for convenience. Class::DBI does not cope well with transactions, much preferring auto-commit to be turned on in your database. 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! There no plans in the near future to improve this situation. If you find yourself using Class::DBI in a transactional environment, you should try to keep the scope of your transactions small, preferably down to the scope of a single method. You may also wish to explore the commit() and rollback() methods of Ima::DBI. (To disambiguate from the commit() and rollback() method in Class::DBI which express very different concepts, we provide dbi_commit() and dbi_rollback() as thin wrappers to the Ima::DBI versions.)

Single column primary keys only
Composite primary keys are not supported. There are currently no plans to change this, unless someone really wants to convince me otherwise.

Don't change the value of your primary column
Altering the primary key column currently causes Bad Things to happen. I should really protect against this.

Cookbook
I plan to include a 'Cookbook' of typical tricks and tips. Please send me your suggestions.

Make all internal statements use fully-qualified columns
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 fine with MySQL (3.22 and up), as that's what Tony develops with. We believe that it also works with PostgreSQL, although some more feedback confirming this would be nice. For the most part it also works with Oracle. 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> Uri Gutman, Damian Conway, Mike Lambert and the POOP group. Please join the POOP (Perl Object Oriented Persistence) list (see http://lists.sourceforge.net/lists/listinfo/poop-group) for discussion and announcements for Class::DBI, Alazabo, Tangram, SPOPS etc. If you use this in production code, you might like to consider mailing me at <classdbi@tmtm.com> to let me know. Then, if I decide to change the interface to anything, I'll let you know first. I like getting feedback anyway, so feel free to mail me if you use this at all, and like it, or don't use it because you don't like it. Or whatever. This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. Ima::DBI, Class::Accessor, base, Class::Data::Inheritable http://www.pobox.com/~schwern/papers/Class-DBI/, Alzabo and Tangram