db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Berman <breitm...@yahoo.com>
Subject Re: Torque with more dynamic DB connections...
Date Tue, 06 Jan 2004 15:18:59 GMT

I don't understand how your suggestion on the bottom
(to use a configuration) will work. I have not found a
way to set a default dsfactory, such as:
torque.dsfactory."default".factory='factory'. Instead,
I seem to need an entry that corresponds to the
Database Name from the schema file.

What am I missing?

--- Ekkehard Kraemer <ekraemer@pluto.camelot.de>
> 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);
>    ...
>    Torque.init(conf);
> Ekkehard 
> To unsubscribe, e-mail:
> torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail:
> torque-user-help@db.apache.org

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

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

View raw message