On 4/20/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 19, 2007 at 04:59:18PM -0400, John Siracusa wrote:
>> The full DBI trace output is included below. I don't see multiple
>> disconnects (or any disconnects, really) in the output, so I'm pretty sure
>> it's only using one $dbh.
>
> I
On Apr 19, 2007, at 9:37 PM, Bill Moseley wrote:
> It's the Manager that seems to be closing the connection.
> Perhaps I'm using it incorrectly?
I don't really know what I'm talking about here, but in our Rose::DB
class[1] we have this,
sub DESTROY { } # Avoid disconnect being called
(the de
On Thu, Apr 19, 2007 at 04:59:18PM -0400, John Siracusa wrote:
> The full DBI trace output is included below. I don't see multiple
> disconnects (or any disconnects, really) in the output, so I'm pretty
> sure it's only using one $dbh.
It's the Manager that seems to be closing the connection.
Per
Given this code:
package A;
use base 'Rose::DB::Object';
__PACKAGE__->meta->setup(table => 't1', columns => [ qw(id a) ]);
our $DB;
sub init_db
{
my $dbh = DBI->connect_cached('DBI:mysql:test', 'root');
return $DB = Rose::DB->new(driver => 'mysql', dbh => $dbh) unless($DB)
On Thu, Apr 19, 2007 at 02:48:24PM -0400, John Siracusa wrote:
> Okay, so:
>
> our $DB;
>
> sub init_db
> {
> ...
> my $dbh = DBI->connect_cached(@params);
> return $DB = App::RDB->new(dbh => $dbh) unless($DB);
> $DB->dbh($dbh);
> return $DB;
> }
I'
On 4/19/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 19, 2007 at 10:35:16AM -0400, John Siracusa wrote:
>> On 4/18/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
>>> This works fine in my base class:
>>>
>>> sub init_db { our $DBH =|| App::RDB->new }
>>>
>>> I've got the same $dbh for the
On Thu, Apr 19, 2007 at 10:35:16AM -0400, John Siracusa wrote:
> On 4/18/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> > This works fine in my base class:
> >
> > sub init_db { our $DBH =|| App::RDB->new }
> >
> > I've got the same $dbh for the life of the program.
> >
> > But, I'd like to try
On 4/18/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> This works fine in my base class:
>
> sub init_db { our $DBH =|| App::RDB->new }
>
> I've got the same $dbh for the life of the program.
>
> But, I'd like to try using DBI->connect_cached directly.
What's your goal? Do you still want just
On Thu, Apr 12, 2007 at 10:54:36PM -0400, John Siracusa wrote:
> > What about using Ima::DBI? Would that stomp on RDB?
>
> I doubt it. A Rose::DB object shouldn't care much what class its dbh is, so
> long as it acts appropriately like a plain DBI dbh.
Sorry, just getting back to this.
I'm mis
On 4/16/07, Tim Bunce <[EMAIL PROTECTED]> wrote:
> > If there's an exception, I believe DBI issues a rollback automatically,
>
> Nope.
Yes, I was looking at the DESTROY code, not the error handling code.
I was talking to Bill about this off-list and he showed me a case
where my strategy fails. I
On Fri, Apr 13, 2007 at 02:28:59PM -0400, Perrin Harkins wrote:
> On 4/13/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> > So, for example, in Catalyst in an end() (or something at the end) you
> > would look for errors and then do a rollback, otherwise commit? And
> > you look at AutoCommit to see
On 4/14/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> So when that die is called the transaction is rolled back and nothing
> sub outer() or do_stuff_and_send_mail() did is in the database. But,
> the mail still got sent (probably saying something happened that
> didn't.)
It sound like you want a
On Sat, Apr 14, 2007 at 12:41:55AM -0400, Perrin Harkins wrote:
> > If you have one sub:
> >
> > do_stuff_and_send_mail {
> >
> > {
> > local $dbh->{AutoCommit} = 0;
> > $object->do_stuff;
> > } # commit (unless nested)
> >
> > send_mail( "do_stuf
On 4/13/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> Catalyst does wrap the requests in eval, so if a controller dies you
> have to look for the exception stuffed int $c->errors somewhere
>
> If you don't mind doing a rollback on all requests then that sure
> makes things nice and simple. Thanks.
On Fri, Apr 13, 2007 at 02:28:59PM -0400, Perrin Harkins wrote:
> On 4/13/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> > So, for example, in Catalyst in an end() (or something at the end) you
> > would look for errors and then do a rollback, otherwise commit? And
> > you look at AutoCommit to see
On 4/13/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> So, for example, in Catalyst in an end() (or something at the end) you
> would look for errors and then do a rollback, otherwise commit? And
> you look at AutoCommit to see if you need to do either of those, I
> assume.
No, it's much simpler t
On 4/13/07, Ovid <[EMAIL PROTECTED]> wrote:
> --- Bill Moseley <[EMAIL PROTECTED]> wrote:
>> I would expect that most applications need a shared dbh -- anything
>> that uses transactions, of course. And, therefore perhaps there was a
>> standard approach.
>
> You know, I was rather surprised about
On Apr 13, 2007, at 12:11 AM, Perrin Harkins wrote:
> My guess is that your code connects to the database from the parent
> process in order to do auto-discovery of the tables, and then you end
> up sharing the same handle when apache forks. Apache::DBI does
> prevent this, so you might consider
Perrin Harkins scribbled on 4/12/07 11:11 PM:
> On 4/12/07, Peter Karman <[EMAIL PROTECTED]> wrote:
>> here's my (admittedly buggy) code for doing this. It caches a single
>> dbh for
>> each unique RDB registry entry combination of domain.type.dsn. I know
>> that it
>> breaks under mod_perl --
--- Bill Moseley <[EMAIL PROTECTED]> wrote:
> I would expect that most applications need a shared dbh -- anything
> that uses transactions, of course. And, therefore perhaps there was a
> standard approach.
You know, I was rather surprised about that myself. I've heard so many
good things about
On Thu, Apr 12, 2007 at 11:59:55PM -0400, Perrin Harkins wrote:
> On 4/12/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> > Speaking of transactions -- anyone ever asked for nested transaction
> > support?
>
> We had a semi-long discussion about that a few weeks back, which you
> can find in the arc
On 4/12/07, Peter Karman <[EMAIL PROTECTED]> wrote:
> here's my (admittedly buggy) code for doing this. It caches a single dbh for
> each unique RDB registry entry combination of domain.type.dsn. I know that it
> breaks under mod_perl -- anyone spot why? (the error I get is from Pg:
> "prepared
>
On 4/12/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
> Speaking of transactions -- anyone ever asked for nested transaction
> support?
We had a semi-long discussion about that a few weeks back, which you
can find in the archives.
> > > What about using Ima::DBI? Would that stomp on RDB?
You'd pr
On Thu, Apr 12, 2007 at 10:54:36PM -0400, John Siracusa wrote:
> Keep in mind that if you replace My::Product in that post with
> My::DB::Object, which is a common base class for all your RDBO-derived
> objects, then you effectively get one connection shared by all objects from
> all tables. Dunno
On 4/12/07 10:11 PM, Bill Moseley wrote:
> Ok, I just have to ask. What are people doing for dbh caching?
> I know this comes up often:
>
> http://thread.gmane.org/gmane.comp.lang.perl.modules.dbi.rose-db-object/1138/f
> ocus=1140
>
> [...] I'm also still trying to understand the point of a n
Bill Moseley scribbled on 4/12/07 9:11 PM:
> Ok, I just have to ask. What are people doing for dbh caching?
> I know this comes up often:
>
>
> http://thread.gmane.org/gmane.comp.lang.perl.modules.dbi.rose-db-object/1138/focus=1140
>
here's my (admittedly buggy) code for doing this. It c
Ok, I just have to ask. What are people doing for dbh caching?
I know this comes up often:
http://thread.gmane.org/gmane.comp.lang.perl.modules.dbi.rose-db-object/1138/focus=1140
Apache::DBI is mentioned, but, unless I'm mistaken, is limited to
mod_perl environments. Can just save $DBH loc
27 matches
Mail list logo
