db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ekkehard Kraemer <ekrae...@pluto.camelot.de>
Subject Re: Torque with more dynamic DB connections...
Date Tue, 06 Jan 2004 07:55:00 GMT
On Mon, 05 Jan 2004 17:29:25 -0600, Rob Gordon <rgordon@mwt.net> wrote:

> I have been following thread regarding using a TorqueInstance with
> multiple > databases, etc.
> I have a similar wish and a proposed solution, if I can get the
> eyes/ears of a developer.
> I want to be able to use the same tables (ie Peers) across multiple
> databases. [...]
> Hence, I want my peers to have their DATABASE_NAME set at runtime, not
> in a static final as is currently done.
> My proposal/question/wish is that the templates/om/Peer.vm be changed to
> include  setDatabaseName()/getDatabaseName() and all the references to
> DATABASE_NAME be changed to invoke the appropriate method.

While digging around a bit, I found that *Criteria* has a "String dbName" parameter in some
of its constructors; you can use that to some effect. At least for simple things, the default
DB is not touched at all if you always specify your own dbName in all Criterias. I verified
it by removing the default DB snippet from my properties, and running all my tests - works.
Sniffing around the code turns up that not everything is fine though... there is the odd method
which uses DATABASE_NAME in any case (for example utility methods of the peers/BasePeer which
create temporary Criterias). The offending methods could be easily changed (without breaking
previous behaviour), I guess. I have no idea how well this works with other components that
use Torque (Turbine...) - no idea if they always use the default DB, or if it can be specified.

Apart from that, I started to change a current CVS checkout so that the "Torque" singleton
goes away. I.e., you can create a "TorqueInstance" in your application and pass it into everything.
It's not difficult, nor are the changes looking like they could break a lot (didn't verify
anything yet though). The point of this would be to be able to run several TorqueInstances
at the same time, each with completely different settings. I'll see whether the Criteria/dbName
approach solves all my problems before I continue working on the singleton approach though.
If someone of you wants to pick up the work, I'll be happy to put a patch together, or just
send the source tree. Again, I have no idea how hard it would be to adapt Turbine, for example,
to use these alternative methods...

Btw, if you simply want to specify the DB to use during startup, and never change it - why
don't you simply use Torque.init(Configuration), and build your own "default" DB properties
on the fly, by copying the properties from your wanted connection? Like

   String someDbInstance="theDbIWantToUseInThisVM";
   conf = (Configuration)new PropertiesConfiguration(propertyFile);


To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

View raw message