The only reason I keep pushing this idea is that I have been bitten by it in the past. And in a OO-relational mapping class as well (although it was a custom class, and not a full system like yours). In the end I wrote a DBI wrapper which handled the differences between MySQL's 'last_insert_id' and PostgreSQL's 'pg_oid_status' which gave me a basic level of DBD agnosticism (well at least the DBD's I cared about that is).
I'm wondering how much stuff from my Whatever::Object::save method needs to be pushed into the subclass. One possibility is just to have each subclass define an "extract_insert_id" method that gets invoked from inside Whatever::Object::save and takes the statement handle as an argument, returning $sth->{whatever} as appropriate to the DBD in question. This, of course, makes the assumption that auto-incrementation will be available in all databases, and that it will be provided via the statement handle. Another possibility is that the entire Whatever::Object::save method should be pushed into subclasses, since there is the possibility that I'll have to generate random primary keys and specify them as part of an insert, in the case of databases that don't do auto-increment.
I guess its a question of how much I care... What databases don't support auto-increment fields? Alas, my experience is limited solely to MySQL.
In reply to Re^6: Auto-Increment and DBD Agnosticism
by skyknight
in thread Auto-Increment and DBD Agnosticism
by skyknight
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |