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, [EMAIL PROTECTED] 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/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
