db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: "inherence" accross 2 differents schemas / reuse some objects from one schema by another one
Date Mon, 25 Jun 2007 14:39:55 GMT
Having multiple DB designers is a common situation and can
be hard to manage even at the DB level.  Adding in the 
management of a common tightly integrated set of access 
objects isn't any easier.  It generally take good 
communications and well defined standard practices to work
well (no different than any multi-developer/multi-area 
project).

That said, here's a couple of extra thoughts on this:

First, I believe that you can use the external-schema syntax 
and the package attribute of the database tag can be used to 
force the java code to be created in different packages.  
This would make it easy to create an "integrated" set of 
DB objects and for build scripts to ignore the "core" 
packages.

Also, you meantion the core being security related. This
raises a design question you'll need to consider. How 
integrated should your security info be with your 
application code?  It is very tempting to integrate at the 
DB level, but what if you decide in the future to use LDAP 
or some other user management mechanism?  

A common way to design for this eventuality is not to use the 
DB code, but to define a set of interfaces that all your 
application code uses to get security info (e.g. user 
validation, user information, user rights, and the like). 
This may not be as convienient as a native access but it makes
migrating to another security mechanism much easier.

Finally, if all else fails and you need to keep them as
separate schema's, is writing code like:

coreTable = CoreTablePeer.retrieveByPK(appTable.getFKField());

A terrible burden? 

That said, having a nojava option might be a nice thing for
situations like this.  Only issue I can think of is that
it might cause compile issues if the external DB jar was
not available.  There might also be object loading issues
if the same packages was split across two jars.  I seem to
remember that one of the JVM's (under linux?) had issues
with this but they may have been resolved.




> -----Original Message-----
> From: Wieger Uffink [Us Media] [mailto:wieger.uffink@usmedia.nl] 
> Sent: Monday, June 25, 2007 3:32 AM
> To: Apache Torque Users List
> Cc: torque-user@db.apache.org
> Subject: Re: "inherence" accross 2 differents schemas / reuse 
> some objects from one schema by another one
> 
> Hi,
> 
> I see your point. I would prefer the external-schema route. 
> If you have separate package names for the core and dependent 
> schemas it should be easy enough to remove the core classes 
> after generating the object model, either manually or by 
> using a build script, but it's not a very elegant solution...
> I don't think there is a 'skipJava' option in the schema, the 
> equivalent of 'skipSql' but something like that would solve 
> your issue, and should not be too hard to hack into the templates. 
> 
> HTH
> Wieger
> 
> -- 
> Us Media
> Stadhouderskade 115
> 1073 AX Amsterdam
> 
> t: +31 20 428 6868
> f: +31 20 470 6905
> w: http://www.usmedia.nl
> 
> ----- Original Message -----
> From: "kstone" <kathyastone@gmail.com>
> To: torque-user@db.apache.org
> Sent: Friday, June 22, 2007 11:48:18 PM (GMT+0100) Europe/Berlin
> Subject: Re: "inherence" accross 2 differents schemas / reuse 
> some objects from one schema by another one
> 
> 
> I see a need to do this myself. Wieger, we are doing 
> something like you
> suggested with one hitch....
> 
> Basically, we have a core application which is like a 
> jumpstart application.
> It contains all of the security DB tables etc.We have 3 
> dependent apps on
> the core and many future ones in design that will need to use 
> all of this
> functionality.
> 
>  So far jarring up the CORE and sending to other apps is 
> fine. Except when I
> need a FK to one of the core tables from the 
> dependentapp-schema.xml. Then
> we have to duplicate this core table entry in the 
> dependentapp-schema.xml.
> This causes two identical classes(one in jar and one in 
> dependent app) to be
> produced which creates a mess.
> 
> Using the external-schema element creates even a bigger mess b/c it
> recreates all of the core om classes in the dependent app.
> 
> We want to eliminate the core classes from being edited in 
> the dependent app
> code base. Only persons who understand how this could affect 
> all apps should
> be diving in here.
> 
> Any more ideas?
> Thanks!
> KStone
> 
> 
> 
> 
> 
> wieger wrote:
> > 
> > Hi Thomas,
> > 
> > When I have two or more web-applications who access the 
> same database I
> > usually create a separate jar which contains the generated torque
> > classes, and perhaps some other shared classes, and include 
> this in each
> > my web-applications. This way you have only one schema file 
> and one set
> > of Torque models to maintain. 
> > Not sure if this is 'best practice' but it works pretty well. 
> > 
> > Kind regards,
> > Wieger
> > -- 
> > Us Media
> > Stadhouderskade 115
> > 1073 AX Amsterdam
> > 
> > t: +31 20 428 6868
> > f: +31 20 470 6905
> > w: http://www.usmedia.nl
> > 
> > 
> > ----- Original Message -----
> > From: "Thomas UNG" <thomas.ung@freesbee.fr>
> > To: torque-user@db.apache.org
> > Sent: Monday, February 19, 2007 4:50:06 PM (GMT+0100) Europe/Berlin
> > Subject: "inherence" accross 2 differents schemas / reuse 
> some objects
> > from one schema by another one
> > 
> > Hi,
> > 
> > I have some questions related to two different webapps 
> sharing the same
> > schema.
> > 
> > Let's say that I ve two webapps A and B pointing to the 
> same DB and the
> > B have the om classes generated by the webapp A in its lib 
> directory.
> > 
> > * In schema A:
> > 
> > <table name="COUNTRY" idMethod="native">
> >   <column name="BASEID" type="INTEGER" required="true" 
> javaName="BaseId"
> > primaryKey="true" autoIncrement="true"/>
> >   <column name="UNIQUENAME"     .../>
> >   [+ some others columns ...]
> > </table>
> > 
> > * In schema B:
> > 
> >   <table name="COUNTRY"
> >         baseClass="A.om.Country"
> >         basePeer="A.om.CountryPeer"
> >         skipSql="true">
> >     <column name="BASEID"         type="INTEGER"
> > required="true" javaName="BaseId" primaryKey="true" 
> autoIncrement="true"
> >  />
> >   </table>
> > 
> > In the classes generated by torque in webapp B, I do have 
> the following:
> > 
> > B.com.Country.getUniqueName()
> > 
> > getUniqueName() is a method inherited from A.om.Country
> > 
> > However, this method returns null because 'uniquename' is a private
> > attribute and torque only do the following selection:
> > 
> > SELECT COUNTRY.BASEID FROM COUNTRY WHERE COUNTRY.BASEID=73
> > 
> > So I do have 2 workarrounds:
> >   - add "UniqueName" column in B schema
> >   - or get the id and use it to retrieve A.om.Country 
> object to get all
> > fields.
> > 
> > Can anyone tell me what is the best practices?
> > 
> > Thanks in advance,
> > Thomas UNG
> > 
> > I am using torque 3.1.1 with turbine 2.3.2
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-user-help@db.apach
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-user-help@db.apache.org
> > 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/%22inherence%22-accross-2-differents-sch
emas---reuse-some-objects-from-one-schema-by-another-one->
tf3253557.html#a11260581
> Sent from the Apache DB - Torque Users mailing list archive 
> at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
> 
> 
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.

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


Mime
View raw message