[Dbix-class] serializing DBIx::Class::ResultSourceHandle (Followup)

[Jose Fonseca]

Hi, thanks for the info on Apache::DBI - I guess it's a very orthogonal
module by design, but I just had not thought of its unwanted implications
for DBIx::Class. Thanks for that.

Just a comment, since you brought that up: When you hand DBIC a connected
DBH via a coderef at connect() time, it also  modifies some internals of
that connection. I have a large app in production right now that has been
partially migrated to DBIC, say 70% is done. But the legacy portion still
uses the original DBH and I found that after DBIC uses that handle, some of
the DBH instance variables had changed. While I have no problems with that
at the moment, I think that when handed an open handle DBIC should not alter
its configuration in any way because (IMHO)we should assume the developer
pre-configured it as needed(why else hand it an already open handle?).
Specifically : it brought up the raiseerror flag and DBH now dies on my
production server when any database error happens on the legacy code.  That
would be desirable on my test server to have it crash as soon as possible on
error, but in production it was an unexpected collateral effect(Documented?
I confess I did not check).

>Yes. So you just do $obj->result_source($schema->source(ref $obj)) there to
add it back.
> I don't see why that's any more work than a reload ... :)

Yeah. I'll profile the app and see, right now reloading and all the database
server doesn't seem to care, it was a smaller penalty than I expected.
Thanks for that once more, appreciate your help.

Regards,
Ze


On Sat, Feb 23, 2008 at 3:24 PM, Matt S Trout <dbix-class at trout.me.uk>
wrote:

> On Thu, Feb 21, 2008 at 02:37:07AM -0300, Jose Fonseca wrote:
> > Hi, sorry for the late reply, been out of the office.
> >
> > >> DBIx::Class works around Apache::DBI being stupid and does a better
> job
> > of it.
> >
> > We're using Apache::DBI extensively in production with DBIx::Class so to
> us
> > it's a real danger if it breaks down. Where, in your experience, was
> > Apache::DBI causing trouble?
>
> Because it mangles the DBI internals to override how you connect to the DB
> - so it can in certain cases hand DBIC a dbh we know is dead straight
> back,
> thus hanging the process entirely.
>
> Since DBIC persists its $dbh internally anyway, you gain absolutely no
> advantage from having Apache::DBI loaded provided you share the
> $schema/$storage object.
>
> > >> Why might I ask? Not doubting you - it just helps to have someone
> else
> > check your logic.
> >
> > "Why" which part ;) ?!
> >
> > If why... "I really need that object in Apache's session memory"
> > For speed only and lifting some weight off of the database backend.
> After I
> > sent that email I rethought about it and gave up speed for
> reliability...it
> > reloads the user object with each request..... I couldn't find the time
> to
> > hack the session/freeze/thaw issue until it worked....
> >
> > Or if why "I am having this problem to start with": here's how I built
> it,
> > nothing exceptional : When the user logs in, the app used to store him
> into
> > $udat{customer} under Embperl. As you know $udat is the Embperl session
> hash
> > and is normally tie'd to a session handling module(Apache::SessionX
> here).
> >
> > And the rest is known here from my previous posts,
> > $udat{customer}->{_source_handle}->{schema} is undef when thaw'ed(more
> > precisely when freeze'd)....
>
> Yes. So you just do $obj->result_source($schema->source(ref $obj)) there
> to add it back.
>
> I don't see why that's any more work than a reload ... :)
>
> --
>      Matt S Trout       Need help with your Catalyst or DBIx::Class
> project?
>   Technical Director
> http://www.shadowcat.co.uk/catalyst/
>  Shadowcat Systems Ltd.  Want a managed development or deployment
> platform?
> http://chainsawblues.vox.com/
> http://www.shadowcat.co.uk/servers/
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.rawmode.org
>



-- =

http://zefonseca.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20080223/8ee=
5eb7c/attachment-0001.htm