in reply to Auto-Increment and DBD Agnosticism

DBI provides a last_insert_id method as of v1.38, but I haven't had luck in getting it to work, at least with my DBD::mysql version (2.9003).

I applaud your goal of DBD-agnosticism. But it's really hard to be DBD-agnostic without also being DBD-specific. Look at all the big cross-platform DB modules out there (Class::DBI for instance). What they do is have all DBD-specific features subclassed out. That's the "right" way to do it. In my own database module, I had to resort to something similar for getting the last-insert-id, as well as schema detection. It goes something like this:

package Foo; sub new { my $class = shift; my $dbh = ... my $subclass = "$class::$dbh->{Driver}{Name}"; eval "use $subclass; 1;" or croak "$dbh->{Driver}{Name} is unsupported"; bless { dbh => $dbh }, $subclass; } sub dbh { $_[0]->{dbh}; }
Then you have a few small DBD-specific modules implementing insert_id:
package Foo::mysql; sub insert_id { my $self = shift; $self->dbh->{mysql_insertid}; } ########### package Foo::Pg; ## notice how Pg requires the table and column, while the ## other DBDs ignore these args sub insert_id { my ($self, $table, $col) = @_; my $id; eval { my $seq = $table . '_' . $col . '_seq'; my $sth = $self->dbh->prepare( "select currval('$seq')" ); $sth->execute; ($id) = $sth->fetchrow_array; $sth->finish; 1; } or die; return $id; } ########## package Foo::SQLite; sub insert_id { my $self = shift; $self->dbh->func('last_insert_rowid'); }
(In my own module, I don't actually bless the objects into the subclass, but I do store the name of the DBD subclass and call insert_id as a class method when I need it) Subclassing is clean and easy to maintain, plus it encourages me to stretch support to as many DBDs as possible.

blokhead

Replies are listed 'Best First'.
Re^2: Auto-Increment and DBD Agnosticism
by skyknight (Hermit) on Jun 22, 2004 at 19:39 UTC
    Thanks, suggesting the paradigm of subclassing to deal with specific DBDs is helpful. I feel like that probably is the right way to deal with cross-DBD inconsistencies. I am already using this for some constructs in my code... For example, I have an abstract class called SQL::Conf that serves as a base for subclasses that parse the connection configurations for specific databases. There is a subclass of it called SQL::Conf::MySQL that parses .my.cnf files, and when you invoke the create_handle method of SQL::DBH it instantiates the appropriate SQL::Conf subclass based on the RDBMS that you specify either as an argument to the method, or as an environment variable. Right now, however, I'm not using such a paradigm for database schema detection... I guess I'm probably going to get burned when trying other databases. :-( Presently I have a SQL::Table class that takes just a handle and a table name, and issues a "describe table foo" query, and populates itself with the returned information. From what you've said, I suppose that that implementation will break when I try something other than MySQL. Ho-hum...