Re: [cgiapp] Re: [OT] Q: Configuring - Same app - Different databases

[Ron Savage <suppressed>]

On Mon, 24 Oct 2005 20:10:48 +0000 (UTC), Mark Stosberg wrote:

Hi Mark

> When I've created apps that can use more than one db, I used the
> config file to drive it all.

I've come round to this, too.

In the past I always preferred to put the config data in the program.

Then I tried letting the user enter $something, and the program used that 
$something to look up config data in a database, but the chicken-and-egg problem 
then arises as to how to connect to the database when $something is meant to 
specify which database to connect to...

My module CGI::Session::MembersArea was created around this time, but I found it 
awkward to use, due mostly to that chicken-and-egg problem not having been 
solved.

Now that I've more-or-less rewritten by vendor-independent db admin tool 
(dbix-admin.cgi, to be released soon), I still have the problem of how to let 
the user specify which db to connect to.

Now I'm trying something else, and that includes using path info to specify 
configuration rather than run mode. Yeah, sacrilege on this list, I know...

Consider:

.../cgi-bin/dbix-admin.cgi
.../conf/dbix-admin/db1.config
.../conf/dbix-admin/db2.config

Then I can say:
http://127.0.0.1/cgi-bin/dbix-admin.cgi/db1
http://127.0.0.1/cgi-bin/dbix-admin.cgi/db2

and the code can use FindBin and 
"$FindBin::Bin/../conf/dbix-admin/$path_info.conf
to find a per-db config file.

Then db1.conf and db2.conf can contain things like:
<Location /cgi-bin/dbix-admin.cgi>

title=DBIx Admin

dsn=dbi:mysql:name-of-db
password=p
username=u

tmpl_path=/apache2/htdocs/templates/dbix-admin/

session_driver=driver:MySQL
session_directory=/temp
session_timeout=+10h

</Location>

which is effortlessly processed via the magic of 
CGI::Application::Plugin::Config::Context.

> Today I would try DBIx::DBH with it's "connect_data()" method.

I can see it's appeal, but having now adopted the wonders of Class::DBI and 
Class::DBI::Loader, neither of which take a $dbh as the default way of 
connecting, I have no need to something like that tool.

> More broadly, I never found a database abstraction technique that I
> was particulary happy with.

Exactly. That's precisely why there are so many of them on CPAN. We're a hard 
bunch to please...

> Now I'm more inclined to support a single database as long as
> possible. :)

Sure. But these days I always develop under MySQL and go live either under 
Postgres or Oracle depending on the project, so single-vendor support is 
history.

> It seems awfully hard to avoid making the application cater to the
> lower-common-demoninator of functionality with a DB abstraction
> layer.

$clever_joke || s/demon/denom/ :-))?

Anyway, $many x $thanx for the reply.
-- 
Cheers
Ron Savage, suppressed on 25/10/2005
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company



---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed