Re: A Growing Dislike for SQL-OOP Mappers

[zby]

Just one word: triggers.

From the Class::DBI documentation:

TRIGGERS
__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 point
s

Triggers are the database way of running some extension code upon creating a record and Class::DBI tries to do it in a manner as similar as possible.

[pg]

First make one thing clear for people who don’t know: those triggers are at application level, not the database level. In general, I am against the idea of using those triggers, unless the database itself does not support database level trigger. Those triggers actually could be much more complex than it first looks like, especially when data integrity becomes a concern and complex locking issues. When you deal with database, leave as much as possible to the database.

[davidrw]

i agree (leave as much as possible to the db -- of roucse there are exceptions to every rlue as well), BUT in reality sometimes that's just not possible. Reasons could include db that doesn't support it, a DBA that doesn't support it, a DBA that can't support it, lack of a DBA altogether, or some combination of those or other reasons. (yes, crappy, but those conditions are out there)

[jk2addict]

Don't forget solar flares! Those are well known to inhibit the availability of triggers. :-)

[jk2addict]

Sure....if I'm using CDBI.

That doesn't change the overall premise. Your modules public API should not be the DBI layers API.