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:[EMAIL PROTECTED] > Sent: Monday, June 25, 2007 3:32 AM > To: Apache Torque Users List > Cc: [email protected] > 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" <[EMAIL PROTECTED]> > To: [email protected] > 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" <[EMAIL PROTECTED]> > > To: [email protected] > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
