RE: CDBI and mod_perl

[prev] [thread] [next] [Date index for 2005/02/23]

> From: Perrin Harkins   Sent: 20 February 2005 21:32
<snip>=20
> > But even if we /could/ do all this, I'm still missing what=20
> > it would buy us (which is what I was really asking for examples of)
>=20
> What you get is the ability to use Class::DBI with database=20
> handles that were not originally created for Class::DBI use.

I still can't see why you would want to share the dbh
between the 2. It sounds down right dangerous to me!
What is wrong with letting the 2 sets of code manage their own
handles? This seems a much cleaner solution, otherwise they may
get in each others way e.g. one app may change some of the dbh
attribs in a way the other doesn't like. Would get messy if one
turned off RaiseError when the other was expecting it. Just as
bad, what if one bit of code sends sql to the server that changes
the sessions settings for the connection, e.g. changing the
collation order, date parsing? The other code has no knowledge
of this. They may even get in each others way if they happen to
use a temp table of the same name. etc, etc.

All these problems go away if you just use 2 handles (and you get
a bunch of advantages to).=20
What advantage does sharing the handle actually give?

> For example, I am trying to do some work with Class::DBI in extensions
> to the Krang CMS. Krang has its own mechanism for getting a database
> handle, which includes application-specific logic about picking the
right=20
> connection to use.  I'd like to be able to override db_Main() and have

> it call the Krang database access routine and just use the $dbh it
gets=20
> back,=20

Why not just get the connection info from the Krang handle and use
that to set up the cdbi connection? If the 2 sets of code are talking
to the same database, then they are integrated, they don't have to use
the same handle.

> but I can't because that handle is not subclassed into the=20
> DBIx::ContextualFetch class.  If I re-bless it, I may break things in=20
> the rest of the Krang application when it gets unexpected results from

> using the $dbh.

Exactly my point! If you share handles something will break somewhere,
if you just share connection info your concerns and better separated
and you don't open the door to these types of (hard to debug) problems.

<snip>

mark
--
This email (and any attachments) is intended solely for the individual(s) t=
o whom addressed.=20
It may contain confidential and/or legally privileged information.=20
Any statement or opinions therein are not necessarily those of ITN unless s=
pecifically stated.=20
Any unauthorised use, disclosure or copying is prohibited.=20
If you have received this email in error, please notify the sender and dele=
te it from your system.=20
Security and reliability of the e-mail and attachments are not guaranteed.=20
You must take full responsibility for virus checking.



Independent Television News Limited,=20

Registered No. 548648 England,

VAT Reg. No: GB 756 2995 81,=20

200 Gray's Inn Road, London WC1X 8XZ,

Telephone: 020 7833 3000.