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);
conf.setString("torque.dsfactory.defaultDbName.connection.url",
conf.getString("torque.dsfactory."+someDbInstance+".connection.url");
...
Torque.init(conf);Ekkehard
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
