On Aug 15, 2007, at 7:56 PM, John Siracusa wrote: > On 8/15/07, Graham Barr <[EMAIL PROTECTED]> wrote: >> On Wed, August 15, 2007 7:54 am, John Siracusa wrote: >>> 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. >> >> the problem is in init_dbh. >> >> Rose::DB does not know that the $dbh it get back from connect is >> not a >> newly connected handle. As a result is still goes ahead and calls >> init_dbh >> which will set all the dbh attributes to the defaults. > > The only dbh attributes that get set in init_dbh() after the > DBI->connect() call are the ones that don't (apparently?) work if > passed as connect options.
You are right, sorry. It is DBI->connect that is setting all the attributes to the requested values. >> Personally I opted to implement the latter. I see no point in having >> multiple Rose::DB objects, that attempt to store state, all >> reference the >> same database handle. That is just asking for trouble. > > I'd like to allow per-object state in Rose::DB independent of the > $dbh. Returning the same object is one optimization too far for me. > Maybe I could make a new_or_cached() method that does it your way...or > maybe you could make it and submit it? :) The way I am doing it now is not generic enough, but when I get back to it I will consider redoing it and submitting it. Graham. ------------------------------------------------------------------------- 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 Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
