db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Monroe <Greg.Mon...@dukece.com>
Subject DbName issues
Date Fri, 08 May 2009 20:42:43 GMT
I was thinking the other day about how to resolve the fact that the same
DBName is used to find the connection information AND the schema information.
This leads to a lot of new user confusion and make it harder than it should to
use the same DB schema object set with different DB connections.

Here's a mostly thought through solution:

First, add a optional new runtime property (I can hear the groans now) of the format:

torque.database.<db handle>.schema=<schema name>

Where:
   <db handle> is something like "bookstore".
  <schema name> is the name used in the schema XML

Next, the Database object would have a schemaName property added.  This gets
set from the config property above or uses the name property if the property does
not exist.

The getDatabaseMap() method in this class would be modified to use the new
schemaName property to find the appropriate schema info.

Next, the DATABASE_NAME static property in the Base* classes should be
deprecated and replaced with a DB_SCHEMA_NAME (or similar) property.
To make it clear what this property is used for.

While we're at it, the TorqueInstance probably needs to have a separate
DatabaseMap collection like the existing Database collection.

This would allow for multiple db handles to be defined that use the same schema
DatabaseMap collection.  The intended purpose is to make the term DBName indicate the
key to the Database object (and related DB connection info) and the term DBSchemaName
indicate the key to the DatabaseMap object.

Once we're there, the generated Base Table classes should have a dbName property
added.  This should be set when the object is populated based on the dbName setting
in the Criteria object used.  If set, this would be used to determine the connection
information to use when the object was saved.

So, if you wanted to use an alternate DB connection with the same classes, all you
need to do is define another set of torque.database.* properties in the config file and
write some code like:

Criteria c =  new Criteria(anotherDbName);
c.add(MyTablePeer.ColA, 3);
List results = MyTablePeer.doSelect( c );

And the result object could be just modified and save() as needed.

IMHO, this would be much cleaner than having to deal with getting connections that
have to be closed and wrapped in final statements, etc.

Thoughts on what I am missing?  Are there "gotcha's" in the Manager code or Id generator
code?

Greg Monroe <Monroe@DukeCE.com> (919)680-5050
Learning Technologies Group - Solutions Team Lead
Duke Corporate Education, Inc.
330 Blackwell St.
Durham, NC 27701



DukeCE Privacy Statement:
Please be advised that this e-mail and any files transmitted with
it are confidential communication or may otherwise be privileged or
confidential and are intended solely for the individual or entity
to whom they are addressed. If you are not the intended recipient
you may not rely on the contents of this email or any attachments,
and we ask that you please not read, copy or retransmit this
communication, but reply to the sender and destroy the email, its
contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is
strictly prohibited.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message