Jonathan Vanasco wrote:
> On Jul 9, 2007, at 7:46 PM, mla wrote:
>> Hmmm. You mean a nightmare to use? They seem really natural to me.
>> Many other ORMs seem to implement them.
>
> no a nightmare to implement.
>
> neither of those actually implement nested transactions.. you can
> nest transactional code, but their support isn't for true nested
> transactions with savepoints ; if you fail in one, you rollback in
> all. i think only db2, oracle, and certain versions of pg support
> actual nested transactions.
Ah. Yes, I'm only talking about nested transactional code.
[snip]
> personally, i don't think transactions belong in an ORM-- they belong
> in your application code.
I guess I'm not always sure where the ORM ends and the app begins.
In Rose::DB::Object, there's logic like this in the save() method:
my $ret = $db->begin_work;
my $started_new_tx = ($ret == IN_TRANSACTION) ? 0 : 1;
eval {
... do stuff ...
if ($started_new_tx) {
$db->commit or die $db->error;
}
};
if ($@) {
$self->error($@);
$db->rollback or warn $db->error if($started_new_tx);
$self->meta->handle_error($self);
return 0;
}
If I understand that correctly, it's trying to keep track of whether
it was responsible for beginning a transaction or not. If not, it
relies on higher-level code to commit/rollback. Otherwise, it tries to
handle it.
It seems like nested transactions would be simpler and more
robust.
my $ret = $db->do_transaction(sub {
...do stuff...
});
unless ($ret) {
$self->error($db->error);
$self->meta->handle_error($self);
return 0;
}
What's the drawback?
Maurice
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Rose-db-object mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rose-db-object
