On 8/15/07 3:11 AM, Michael Lackhoff wrote:
> On 14.08.2007 22:43 John Siracusa wrote:
>> Assuming your have AutoCommit turned off, that's why $obj was not
>> saved. The rollback rolled back everything done since the last
>> begin_work().
>
> Well, I didn't switch AutoCommit on or off
Was it on or off when you connected to the database?
> and I didn't do a rollback myself, so the question remains why the default
> configuration with Apache::DBI and init_db(MyApp::DB->new) does a rollback
> when the database is accessed from a new db (in the helper)
In your example:
some_helper_that_uses_db(); # rollback here
I assumed you called rollback() yourself inside that function. As
discussed, Apache::DBI calls rollback() at the end of the request if
AutoCommit is off, and do_tranaction() calls rollback() if the code it's
passed to execute dies. That's it.
> There was no error and I don't understand why $obj wasn't committed in
> the $db->commit at the very end.
It wasn't committed because the rollback that happened in
some_helper_that_uses_db() "undid" the as-yet-uncommitted $obj->save.
Again:
my $obj = Products->new(db => $db);
...
$obj->save;
some_helper_that_uses_db(); # rollback here
If there was no commit() between $obj->save and the rollback that you say
happened inside some_helper_that_uses_db(), then $obj is not saved.
> Why would I need a second commit before the helper?
The real question is, why is some_helper_that_uses_db() causing a rollback?
Turn on DBI->trace(1) to be sure it actually is, and maybe try to create a
small test case.
-John
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Rose-db-object mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rose-db-object
