db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Eade <se...@backstagetech.com.au>
Subject Re: Logical vs. physical db names - expanding the role of torque.database.name
Date Fri, 07 Feb 2003 00:33:59 GMT
Hi Stephen,

On 6/02/2003 2:26 AM, "Stephen Haberman" <stephen@beachead.com> wrote:
> On Wed, Feb 05, 2003 at 03:04:07PM +1100, Scott Eade wrote:
>> What do others think?
> 
> Makes sense to me.
> 
> So, if I understand it correctly, current the logical name is pulled
> from the *-schema.xml file, and dropped in the sqldb.map file that
> maps schema to (currently logical).
> 
> You're saying this doesn't make sense because in fact we want SQL
> generation tasks to use the physical database name, which does not
> come from the *-schema.xml file, but is in the
> 'torque.database.name' property.
Yes.
> 
> And the general solution would be to modify the SQL generation tasks
> to not use the sqldb.map file to get the (wrong) database name, but
> instead do something like add a 'databaseName' attribute that you
> can set in the build-torque.xml to '${torque.database.name}'.
I'll check, but I think sqldb.map is only used by insert-sql, so the
solution would be to put the physical rather than the logical name into
sqldb.map in the first place.
> 
> The only problem I foresee is people not having the
> torque.database.name property currently set. As I look at my current
> setup, torque.database.name is only set in the runtime
> configuration.
> 
> You'd have to find an elegant way of either finding a good default
> for torque.database.name if it is not set (e.g. default to the
> logical name from *-schema.xml) or else do something like prompt the
> user that they need to set it (I'd go for the first one).
Agreed - if torque.database.name does not exist then we can retain the
existing behaviour in sqldb.map (by using torque.project, the name attribute
of the database element in the schema, or whatever it is).

> 
> - Stephen

I may attempt to find my way through the morass to implement this soon, but
as this only really affects the generation of the DDL I probably won't look
at it until after I attack the runtime issues associated with PostgreSQL.

Cheers,

Scott
-- 
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
.Mac Chat/AIM: seade at mac dot com
 


Mime
View raw message