On Aug 15, 2007 3:49 PM, Tim Bunce <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 15, 2007 at 01:06:01PM -0500, Graham Barr wrote:
> >
> > 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 s
On Aug 17, 2007, at 3:53 PM, John Siracusa wrote:
>>> Finally, I suppose I could change the default implementation of
>>> init_db() to be more like this instead:
>>>
>>> sub init_db { $DB ||= Rose::DB->new }
>>>
>>> But that'd be quite a behavior change, and it'd have its own set
>>> of probl
On 17.08.2007 22:53 John Siracusa wrote:
>> So, if I understand it right, there are really two problems:
>> - no rollback when it should be (my do_transaction above)
>> - a rollback when there should be none (your warn)
>
> Once the database handle is reset to auto-commit, any subsequent
> rollba
>
> I just meant that it'd be a change in historic behavior that could
> break some people's code when they upgrade (not that RDBO is 1.0 yet,
> but it's still nice to avoid this kind of thing, if possible).
This is off-topic, but what lies ahead on the road between RDBO 0.7xx and
1.0? Are there
On 8/17/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> On 17.08.2007 16:20 John Siracusa wrote:
> > On 8/15/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> >> my $db = My::DB->new();
> >>
> >> $db->do_transaction(
> >> sub {
> >> my $o = My::Thing->new();
> >>
On 17.08.2007 16:20 John Siracusa wrote:
> On 8/15/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
>> my $db = My::DB->new();
>>
>> $db->do_transaction(
>> sub {
>> my $o = My::Thing->new();
>> $o->foo(123);
>> $o->bar(456);
>> $o->sa
On 8/17/07, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> Do you think that Apache::DBI should be doing this on every connect
> call to begin with? I suppose it depends on whether it is trying to
> provide safety for ported CGI scripts, or a general purpose persistent
> database connection.
Exactly
On 8/17/07, John Siracusa <[EMAIL PROTECTED]> wrote:
> But really, I'd like to solve this somehow so the default way works as
> well. It would be nice if I could ask Apache::DBI not to call
> reset_startup_state(), perhaps by passing a special connect attribute:
Do you think that Apache::DBI shou
On 8/15/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> my $db = My::DB->new();
>
> $db->do_transaction(
> sub {
> my $o = My::Thing->new();
> $o->foo(123);
> $o->bar(456);
> $o->save;
> die "Does it rollback?";
>
On Wed, Aug 15, 2007 at 10:17:07PM -0400, John Siracusa wrote:
> On 8/15/07 10:08 PM, Graham Barr wrote:
> > On Aug 15, 2007, at 7:56 PM, John Siracusa wrote:
> >> The only dbh attributes that get set in init_dbh() after the
> >> DBI->connect() call are the ones that don't (apparently?) work if
> >
On 8/15/07 10:08 PM, Graham Barr wrote:
> On Aug 15, 2007, at 7:56 PM, John Siracusa wrote:
>> 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->c
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
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
On Wed, Aug 15, 2007 at 01:06:01PM -0500, Graham Barr wrote:
>
> 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 standard approach I rec
On Wed, Aug 15, 2007 at 01:06:01PM -0500, Graham Barr wrote:
>
> in Rose::DB AutoCommit has a default of 1. In my case that is the default
> I want. But when Rose::DB->new is called and there is currently an active
> transation, the code in init_dbh will reset AutoCommit to 0.
Perhaps connect_cac
On 8/15/07, Graham Barr <[EMAIL PROTECTED]> wrote:
> So either init_dbh needs to be able to detect that the $dbh it gets is a
> reuse of an existing connection, or Rose::DB->new needs to return the same
> object for all calls for the same connection.
Even if init_dbh is changed, I think Apache::DB
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
On 15.08.2007 18:47 Perrin Harkins wrote:
> I have a guess. Looking at the new code in Apache::DBI, I see that it
> now tries to reset the state of the $dbh every time you call
> connect(). This probably breaks the begin_work() state.
>
> I'm not sure why this was added, since it seems like thi
On 8/15/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> Well, I didn't switch AutoCommit on or off 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 d
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
On 14.08.2007 22:43 John Siracusa wrote:
> On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
>> On 14.08.2007 20:34 John Siracusa wrote:
>>> On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
$db->begin_work;
my $obj = Products->new(db => $db);
...
$obj->save;
s
On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> On 14.08.2007 20:34 John Siracusa wrote:
> > On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> >> $db->begin_work;
> >> my $obj = Products->new(db => $db);
> >> ...
> >> $obj->save;
> >> some_helper_that_uses_db(); # rollback here
>
On 14.08.2007 20:37 Bill Moseley wrote:
> On Tue, Aug 14, 2007 at 08:28:40PM +0200, Michael Lackhoff wrote:
>> > Have you also looked at Roes::DB's do_transaction() ?
>>
>> I know that this is another possible variant but because there is so
>> much code I didn't want to squeeze it into a single
On 14.08.2007 20:34 John Siracusa wrote:
> On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
>> $db->begin_work;
>> my $obj = Products->new(db => $db);
>> ...
>> $obj->save;
>> some_helper_that_uses_db(); # rollback here
>> my $obj2 = Customers->new(db => $db);
>> ...
>> $obj2->save;
>> $db-
On Tue, Aug 14, 2007 at 08:28:40PM +0200, Michael Lackhoff wrote:
> > Have you also looked at Roes::DB's do_transaction() ?
>
> I know that this is another possible variant but because there is so
> much code I didn't want to squeeze it into a single call. It would do
> after some reorganization b
On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> $db->begin_work;
> my $obj = Products->new(db => $db);
> ...
> $obj->save;
> some_helper_that_uses_db(); # rollback here
> my $obj2 = Customers->new(db => $db);
> ...
> $obj2->save;
> $db->commit;
>
> When I ran this code $obj2 was saved but
On 8/14/07, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On 8/14/07, John Siracusa <[EMAIL PROTECTED]> wrote:
> > I looked for that and didn't see it, and still don't see it.
>
> Sorry, this was actually changed already. I was looking at an older release.
Phew. Because I have stuff going to produ
On 14.08.2007 20:20 Bill Moseley wrote:
> On Tue, Aug 14, 2007 at 11:57:27AM +0200, Michael Lackhoff wrote:
>> my $db = MyApp::DB->new;
>> $self->my_db($db); # a new db for a new transaction
>> $db->begin_work; # Start transaction
>>
>> ... create two objects and save them ...
>>
>> die "Does i
On 14.08.2007 18:54 Perrin Harkins wrote:
> On 8/14/07, John Siracusa <[EMAIL PROTECTED]> wrote:
>> The simplest way to do this is to leave everything as per the
>> defaults, and just use Apache::DBI.
>
> Note that Apache::DBI also does the automatic rollback for you, but
> only if you have AutoC
On Tue, Aug 14, 2007 at 11:57:27AM +0200, Michael Lackhoff wrote:
> my $db = MyApp::DB->new;
> $self->my_db($db); # a new db for a new transaction
> $db->begin_work; # Start transaction
>
> ... create two objects and save them ...
>
> die "Does it roll back?";
> $db->commit;
>
> But when I run
On 8/14/07, John Siracusa <[EMAIL PROTECTED]> wrote:
> I looked for that and didn't see it, and still don't see it.
Sorry, this was actually changed already. I was looking at an older release.
- Perrin
-
This SF.net email i
On 8/14/07, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On 8/14/07, John Siracusa <[EMAIL PROTECTED]> wrote:
> > Doesn't Apache::DBI just care that $dbh->{AutoCommit} is false at the
> > time it checks in the cleanup handler?
>
> Look further up in the code. It never pushes the handler unless
> Au
On 8/14/07, John Siracusa <[EMAIL PROTECTED]> wrote:
> Doesn't Apache::DBI just care that $dbh->{AutoCommit} is false at the
> time it checks in the cleanup handler?
Look further up in the code. It never pushes the handler unless
AutoCommit is off. Probably a mistake in my opinion. If others
ag
On 8/14/07, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> Note that Apache::DBI also does the automatic rollback for you, but
> only if you have AutoCommit off when you connect. If you connect with
> AutoCommit on, you have to handle the rollback yourself.
Doesn't Apache::DBI just care that $dbh->{
On 8/14/07, John Siracusa <[EMAIL PROTECTED]> wrote:
> The simplest way to do this is to leave everything as per the
> defaults, and just use Apache::DBI.
Note that Apache::DBI also does the automatic rollback for you, but
only if you have AutoCommit off when you connect. If you connect with
Auto
On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> And to the second alternative, how do I have to setup RDBO with mod_perl
> to share a db (and dbh with it) for everything within one
> process/request but not across multiple processes?
The simplest way to do this is to leave everything as
On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> Only question: Is it really possible to call rollback as a class method
> or do I have to call it on the specific object that started the transaction?
You have to call it on the database handle that started the
transaction. If all of your
On 14.08.2007 17:50 Perrin Harkins wrote:
>> do you have any pointer on how this is done (correctly)?
>
>$r->push_handlers(PerlCleanupHandler => sub {
>MyApp::DB->rollback();
>});
Thanks! That's exactly what I needed. I found already that there is a
PerlCleanupHandler directive i
On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> Well, my understandig was that if perl dies within a transaction it (or
> DBI) would do a rollback, from your answer I guess this is not the case.
No. Your database will do it if you cut the connection and there is
uncommitted work, but pe
On 14.08.2007 16:54 Perrin Harkins wrote:
>> $db->begin_work; # Start transaction
>> die "Does it roll back?";
>> $db->commit;
>
> I don't see any rollback there. It's a common practice to put an
Well, my understandig was that if perl dies within a transaction it (or
DBI) would do a rollback,
On 8/14/07, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> my $db = MyApp::DB->new;
> $self->my_db($db); # a new db for a new transaction
> $db->begin_work; # Start transaction
>
> ... create two objects and save them ...
>
> die "Does it roll back?";
> $db->commit;
I don't see any rollback there.
Hello,
I thought I understood how to organize several write operations within a
transaction but it still doesn't work the way I do it.
Here is what I have so far:
In my base class:
sub init_db {
my $self = shift;
my $db;
if (not $self->my_db) {
$self->my_db( MyApp::DB->new() )
42 matches
Mail list logo
