Ekkehard,
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?
Thanks,
Marc
--- Ekkehard Kraemer <[EMAIL PROTECTED]>
wrote:
> On Mon, 05 Jan 2004 17:29:25 -0600, Rob Gordon
> <[EMAIL PROTECTED]> 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);
>
>
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]
>
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
