Re: "Dynamic" database handles?

[prev] [thread] [next] [Date index for 2005/01/24]

On Mon, 24 Jan 2005, William McKee wrote:

> On Sat, Jan 22, 2005 at 06:47:18PM -0600, Jason Gessner wrote:
> > The problem with C::DBI is that your connection is a module variable  
> > and is never reinitialized (unless you force it to be).  What this  
> > means is that Virtual host A will start accessing Virtual host B's  
> > database if that particular apache child has already been used against  
> > virtual host A.  Sucks.
> 
> But doesn't this assume that you are using the same module to access
> different databases? If you use a different namespace for each database
> table you are accessing, I would think you'd be spared these headaches.
> I know this is not always feasible, esp. for the type of application
> that the OP was describing.

The database connection is part of the context of the particular user's 
session. Whatever mechanism you use to save that state (cookies etc.), 
add this as one more variable. I would be concerned for interaction with 
Apache::DBI . Caveat : I haven't done any of this, but I have plans to do 
so at some point.

One argument made in favor of putting "ownership" of a record into the 
database rather than using namespaces and database-level users is backup: 
the claim is that if you use table ownership you have no idea to whom this 
data belongs. To some extent the validity of this argument depends on your 
database: MySQL is very different than Oracle or even Postgresql, lacking 
many of the more sophisticated features of the latter two. 
Seems to me that if you have separate database with the same structure
on a per-customer (or whatever you're tracking) you can combine the name 
of the customer with the usual name of the database and that gives you 
some extra clue. At some point you're going to have similarly named tables 
in different databases of disparate applications; I think its specious to 
claim that you've got this table lying around and no clue who it belongs 
to.