db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michel Beijlevelt / Lucka <...@lucka.nl>
Subject Re: different internal variable names
Date Mon, 04 Aug 2003 12:42:21 GMT

the opinion about  tight or loose coupling is also influenced by the 
frequency of changes in the RDBMS schema.

If my application is - through Torque - tightly coupled with the RDBMS, 
it will almost certainly fail with an exception upon a moderately 
significant change in the RDBMS. Which is good, because it will 
precisely pinpoint the change, and makes 'sure' (well, fairly sure that 
is :-) that my appliction only runs against the RDBMS that is was 
designed for and none other.

But I agree, having the possibility of  making Torque more loosely 
coupled from the RDBMS would be a nice feature. It could be implemented 
by allowing specifying aliases for db objects in the XML schema 
definition which does seem to be fairly simple to implement, but maybe a 
more sophisticated abstraction layer isn't that hard to make either.

gr. Michel

Manske, Michael wrote:

>i knew that such a discussion would come up and it depends on the point of
>view of each indivual user. :)
>>I don't know, I think I would Torque rather see more tightly coupled 
>>with the RDBMS and dump the XML schema entirely.
>if you have control over database structure and changes of the database
>structure, then you will
>perhaps prefer a strict coupling. But if not (like me), you will always
>prefer loose coupling to be more independent of changes made by another dev
>>My RDBMS already has a schema, which would be the metadatabase in the 
>>systems tables. So why create another definition in XML of the same 
>>database and tables?
>If you have to support different RDBMS the metadescription in some "system
>tables" will get useless.
>>Torque's capability of abstraction of the RDBMS-specific 
>>isssues comes 
>>in quite handy here. The process could be automated by having Torque 
>>generate the XML definition from a JDBC conncection, and then 
>>the om from that XML, but I haven't tried that yet.
>Thats what i'm talking about, we are working with torque this way because we
>have to deal
>with a couple of already existing databases.
>And yes, torques abstraction is somewhat of handy - thats why we use it. :-)
>Loose coupling means among other things to hide the physical database
>structure completely from the objects, which have to access the database. A
>layer (like torque) will then act as mediator between objects and database.
>So if you would have problematic identifiers like "short", you would be
>easily able to map them to another name, which could then be used in java
>objects, e.g. map "short" to "short_descr".
>There is already some kind of support for this but at the moment it isn't
>suitable at all.
>I guess torque is so popular because of his abilities to generate more or
>less useable code and the usage of a xml schema at runtime (respectively at
>application startup) would possibly be contradictory to the generator BUT it
>would also provide more independency from used database structure.
>I'm not sure wheter this is a mainly intention of torque but i would be glad
>if the devs would expand
>support for loose coupling (at least for mapping of table/column names to
>java names) in future versions...
>PS: pros and cons of loose coupling will always be a matter of opinion

To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

View raw message