Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Users List" <torque-user@db.apache.org>
Message-ID: <3F2E54AD.70504@lucka.nl>
Date: Mon, 04 Aug 2003 14:42:21 +0200
From: Michel Beijlevelt / Lucka <mbe@lucka.nl>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Apache Torque Users List <torque-user@db.apache.org>
Subject: Re: different internal variable names
References: <E106F355E0DBD411B1120050DA406AA6F6DC37@datnt6.dat.de>
In-Reply-To: <E106F355E0DBD411B1120050DA406AA6F6DC37@datnt6.dat.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Howdy,

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:

>hi,
>
>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
>team. 
>
>  
>
>>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 
>>generate 
>>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...
>
>regards,
>Michael
>
>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