[Dbix-class] An idea about "disconnecting cleanly"

[Brandon Black]

On 2/6/06, Leandro Hermida <leandro.hermida at unibas.ch> wrote:
>
> Hello,
>
> My apologies if this is not the right forum to express any ideas, this is my
> first time ever writing to a development list.

Welcome :)  This is a good place to bring up these kinds of things. 
Another option is the irc channel #dbix-class on server irc.perl.org.

> I really like DBIx::Class
> and have been testing it with some of my development databases.  I have an
> idea about the area of DBIx::Class::Manual::Cookbook section called
> "disconnecting cleanly".

DBIx::Class' statement handles seem to already have a ->sth->finish
hook in the DESTROY method of ::Storage::DBI::Cursor, so I think we're
covered on that front.

I've made a minor update to the Cookbook now to use
"->storage->disconnect" instead of "->storage->dbh->disconnect" (as
"->dbh" is DBI-specific, and in theory we will have non-DBI Storage
backends in the future).

I also committed another set of changes just now that adds a dbh
rollback (if appropriate) whenever ->disconnect gets called, and does
->disconnect on Storage::DBI objects' ->DESTROY.  These seem to work
fine and not break anything else in the design to me, but we'll see if
everyone else agrees once they get a chance to see/test that in trunk.
 Of course, if one defines a live connection on a schema class (as
opposed to a schema object), DESTROY won't ever get called.  People
who do that will still need to remember to disconnect manually if they
need to via ->storage->disconnect.

I'm not of the opinion that we can/should play with signals in
DBIx::Class, as we can't really predict what people's app code might
be doing with various signals (someone might use SIGINT as a runtime
IPC mechanism, and that's perfectly legal if slightly insane).  But
again, people can follow the Cookbook example, or expand that basic
concept to cover other signals, etc in their personal schema
subclasses or in app code.

-- Brandon