(RADIATOR) Fwd: Dynamic DBSource

[Matt S Trout]

> *This message was transferred with a trial version of CommuniGate(tm) Pro*
>
> >From: "Oscar L. Garzón" <ogarzon at andinet.com>
> >To: "Sergio González" <sagonzal at sky.net.co>
> >Subject: Dynamic DBSource
> >Date: Tue, 28 Jan 2003 05:10:03 -0500
> >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> >Importance: Normal
> >
> >What would be the best way to implement dynamic dbsource specifications
> >based on run-time variables, what I actually need is what the following
> >sentence says, but as you my guess, the do not work because sql
> >connections are handled at startup.  ( %R would be realm )
> >
> >DBSource DBI:Pg:dbname=%R
> >DBUsername %R

Not sure I can help you if you need a different user/server, but logging
to different databases on the same system should be fairly trivial; simply
construct your SQL statements as UPDATE %R.tablename SET ... or similar.
If you need to be using different logins entirely, possibly some sort of
proxying system would be your best answer (there's a DBI-based one you
might be able to use since you're running Perl already) - so a single
apparent login and db server to Radiator becomes multiple on the other
side.

I don't think you'd really want to do this otherwise anyway, since setting
up and tearing down your database connection every time you have a hit is
horrifically expensive - probably more so than the proxying solution
described above.

OR - the unpleasant but ultimately perhaps the simplest way - knock up a
quick script that generates a separate clause for each potential Realm.

- Matt S Trout

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.