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 <[email protected]> (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.
