++ed by:

2 PAUSE users
5 non-PAUSE users.

Tony Bowden


        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->columns(All => qw/artistid name/);
        Artist->has_many('cds', 'CD' => artist);

        package CD;
        use base 'Music::DBI';
        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->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.

        # 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

Set up a 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 for details.

Set up a table for your objects to be stored in.

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),
Inherit from 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.

        package CD;
        use base 'Class::DBI';
Declare a database connection

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()]

Declare the name of your table

Inform Class::DBI what table you are using for this class:

Declare your columns.

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:



        __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 = 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_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');

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.

If the create() fails, then by default we throw a fatal exception. If you wish to change this behaviour, you can set up your own subroutine to be called at this point using 'on_failed_create'. For example, to do nothing at all you would set up:

        __PACKAGE__->on_failed_create( sub { } );


        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.



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.


        $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. This should help considerably with memory when accessing a large number of search results.


        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;



        $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',


        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.



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.

And of autocommitting:

                # Turn autocommitting on for this object.

                # Each accessor call causes the new value to immediately be written.

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.


                $commit_style = Class->autocommit;

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



Any changes you make to your object are gathered together, and only sent to the database upon a commit() call.

Note: If you have transactions turned on (but see "TRANSACTIONS" below) you will need to also call dbi_commit(), as this commit() merely calls UPDATE on the database).

If you call commit() when autocommit is on, it'll just silently do nothing.



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.


        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 = $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: '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',


        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() 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 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.

Ima::DBI queries

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, SUM(cd.id) AS cds
                  FROM artist, cd
                 WHERE artist.id = cd.artist
                 GROUP BY artist.id
                 ORDER BY cds DESC
                 LIMIT 10

Then you can set up a method that executes these are returns the relevant objects:

  sub top_ten {
    my $class = shift;
    my $sth = $class->sql_top_ten;
    return $class->sth_to_objects($sth);

The $sth which we use to return the objects here is a normal DBI-style statement handle, sof 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.


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.


        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.



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.



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.



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:

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

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



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


Uri Gutman, Damian Conway, Mike Lambert, Tatsuhiko Miyagawa and the POOP group.


There are two mailings lists devoted to Class::DBI, a 'users' list for general queries on the use of Class::DBI, bug reports, and suggestions for improvements or new features, and a 'developers' list for more detailed discussion on the innards, and technical details of implementing new ideas.

To join the users list visit http://groups.kasei.com/mail/info/cdbi-talk.

To join the developers list visit http://groups.kasei.com/mail/info/cdbi-dev.


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.


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