[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: svn commit: r571790 - in /db/torque/runtime/trunk/src/java/org/apache/torque: TorqueInstance.java manager/AbstractBaseManager.java Thomas Vandahl Thu Sep 06 00:01:41 2007

Thomas Fischer wrote:
Sorry that I did not write an email sooner, but I'm -0.5 on this change. If
the name of the default database should be "default", then the user should
torque.database.default = default
to Torque.properties.

I see no reason why "default" should be a reserved database name. On the
other hand, it has confused users in the past, and it is difficult to
achieve a clean shutdown (I'm rather sure Torque will try to close the
default datasource twice now on Torque.shutdown().)

No, it won't. The code part sets defaultDsfIsReference to true which takes care of this situation (introduced by yourself, Rev 393063, a fix for TRQS322, where we discussed this before):

tfischer             19.10.2005 22:36:03
The Data Source Key "default" is now again mapped to the default data source.
A test case is added to check that the behaviouris retained in the future.
Fixes TRQS322.

The copy of the DataSource has been there for ages. "default" has always been a reserved name for a database, the whole feature torque.database.default would not make sense otherwise. Turbine relies on that feature because it helps you to decide (at runtime, via configuration) which of the databases to use for authentication.

I'd think it the cleanest solution if Turbine would not use a database
name. Torque uses the default database whenever no database name is better.
Another good solution would be if Turbine would ask Torque for its default
database (via Torque.getDefaultDB()) instead of just using "default". Both
will be backward-compatible down to Torque 3.1 at least.

For the time being, the Turbine jar comes with compiled-in Torque OM classes. These use "default" as their database name, to make use of the above mentioned feature. Mind you, Torque peers still contain the database name as a static. I agree that the behavior you describe would be desirable but then again this is an issue for Torque to handle.

If you still think this mapping is necessary for Turbine, and the
properties workaround is no good, then please look into the shutdown issue
and document the mapping you have done.

I still consider this a feature and all I did was to make it work correctly under all circumstances. The shutdown issue is taken care of. (see line 716 in TorqueInstance.java) Concerning the documentation of this feature, see http://db.apache.org/torque/releases/torque-3.3/runtime/reference/initialisation-configuration.html the section about database handles.

If it is agreed to revert this change, I'd offer to do it, to make up
partly for my delay in answering.

For reasons given above.

Bye, Thomas.

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]