db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: package attribute on table?
Date Mon, 12 Feb 2007 15:10:11 GMT
I have to say I'm -0.5 or so on this.  But this is
an initial gut feel based on my experiences of 
recently fixing a lot of package related problems
in the templates and a memory of a lot of similar
problems/issues that occure with each new version.

IMHO, this is because it is VERY difficult to test
all the existing combinations of build properties
prior to release.  I'm just not sure that this 
feature would be used enough to justify the 
effort to maintain it.

That said, I think the right solution would be 
to make the external schema stuff work right.  
The only reason I can see for not having the 
external foreigns supported is that there is
no guarentee that they are in the same DB 
schema or even server.  E.g., users info on
one server/schema and app info on an other.

Without looking at the code, maybe the way
to do this is to add a optional "database" 
attribute to the foreign-key schema element and
matching class. This would allow the foreign
key stuff to fully identify the related column
and generate the right code.

Just some initial thoughts on this, I could 
probably be persuaded otherwise..

Greg

> -----Original Message-----
> From: Thomas Fischer [mailto:fischer@seitenbau.net] 
> Sent: Monday, February 12, 2007 7:10 AM
> To: Apache Torque Developers List
> Subject: RE: package attribute on table?
> 
> Brendan,
> 
> if adding a package attribute to the tables works without 
> adding too much complexity, I'd consider that a good addition 
> to Torque.
> I'd think the following needs to be done to implement this:
> - adding the logic to read the package attribute from the 
> schema.xml (I understand that most of this is already there)
> - adding the logic to the templates to get the imports 
> correct Do you see any other places where changes must be made ?
> 
> I'd see the package attribute of the database element as a 
> default value, which can be overridden by a package attribute 
> of the database. So the place where the <DatabaseName>MapInit 
> class is generated would still be determined by the package 
> attribute of the database element.
> 
> Are you aware of the subpackage features
> (http://db.apache.org/torque/releases/torque-3.3
> /generator/properties-reference.html, search for 
> "torque.subpackage", there are several properties)? How would 
> you handle this ? E.g. where would you put the MapBuilder classes ?
> 
> Do not expect to get this feature into Torque 3.3. Hopefully, 
> the current RC is also the final version, and after this the 
> current plan is to change a few internals of Torque, which 
> will take some time.
> 
>       Thomas
> 
> "Brendan Miller" <bmiller@dotster.com> schrieb am 09.02.2007 21:17:01:
> 
> >
> > (Sorry if this is rather long; I felt it necessary to give a full 
> > account
> 
> > of my problem statement and analysis of a possible solution 
> to get the 
> > best feedback possible.)
> >
> >
> > My group would like to create the Torque classes for each table in 
> > different Java namespaces by grouping related tables together as we 
> > deem appropriate.  We have experimented with splitting up 
> the database 
> > schema into multiple XML schema definitions and using 
> > <external-schema> to reference the related schemas so that 
> foreign-key 
> > references to tables in other namespaces can still work.  
> This method 
> > is somewhat satisfactory, except that the Torque generator 
> appears to 
> > mark tables referenced in/by external schemas as 
> second-class citizens 
> > and fails to generate the doSelectJoin<OtherTable> methods in the 
> > Peers and the get<CollectionOfRelatedTables> methods in the 
> Objects.  
> > I've analyzed the code, and I think it has something to do with the
> isForReferenceOnly()
> > notation.
> >
> > I considered removing the reference-only limitation of external 
> > schemas, but was wary of hidden implications if it was removed.  
> > Moreover, resorting to external schemas and changing their behavior 
> > felt lke a workaround to what I'd like to see anyway.
> >
> > Rather, the real feature I'm after is a package attribute 
> on the table 
> > element in the schema that would be propagated to each Table object.
> > If this schema definition
> >
> >   ...
> >   <table name="author" package="com.example.author">
> >     <column name="author_id" required="true" primaryKey="true"
> > type="INTEGER"/>
> >     <column name="first_name" required="true" 
> type="VARCHAR" size="128"/>
> >     <column name="last_name" required="true" type="VARCHAR" 
> size="128"/>
> >   </table>
> >   <table name="book" package="com.example.book">
> >     <column name="book_id" required="true" primaryKey="true"
> type="INTEGER"/>
> >     <column name="title" required="true" type="VARCHAR" size="255"/>
> >     <column name="isbn" required="true" type="VARCHAR" size="24"
> > javaName="ISBN"/>
> >     <column name="publisher_id" required="true" type="INTEGER"/>
> >     <column name="author_id" required="true" type="INTEGER"/>
> >     <foreign-key foreignTable="author">
> >       <reference local="author_id" foreign="author_id"/>
> >     </foreign-key>
> >   </table>
> >   ...
> >
> > caused he generator to create
> >
> >   .../com/example/author/BaseAuthorPeer.java
> >   .../com/example/author/BaseAuthor.java
> >   .../com/example/author/AuthorPeer.java
> >   .../com/example/author/Author.java
> >   .../com/example/book/BaseBookPeer.java
> >   .../com/example/book/BaseBook.java
> >   .../com/example/book/BookPeer.java
> >   .../com/example/book/Book.java
> >
> > with all the doSelectJoinTable()s in the Peers and 
> > collRelatedTable/getRelatedTables()/addRelatedTable()/etc. in the 
> > Objects, I'd be happy.
> >
> > To research this, I again examined the generator/templates 
> and found 
> > that the Table class
> > 
> (generator/src/java/org/apache/torque/engine/database/model/Table.java
> > ) in fact has a 'pkg' member with getPackage() and setPackage() 
> > methods.
> > The curious thing is that in loadFromXML() the following line is 
> > commented out:
> >
> >         // pkg = attrib.getValue("package");
> >
> > I've traced this line back to the initial version of Table.java
> > (r227530) in which there were no getters/setters and the pkg member 
> > was commented out as well.  This changed in r228416 when jmcnally 
> > added the ability to reference tables in external schemas.  The pkg 
> > member was uncommented, the getters/setters added, the 
> > 'forReferenceOnly' logic was added, but the above 
> > atttrib.getValue("package") line was left commented.  The 
> commit log from these additions is as follows:
> >
> >   added the ability to reference tables in a different schema.  The
> objects
> >   defined in the referencing schema are aware of the objects in the
> >   referenced schema.  But the object model in the 
> referenced schema is
> >   unaffected.  Does not currently handle a circular relationship.
> >
> >   The tables in the related schemas should be in the same database.
> >
> >   Useful for addons/optional components that should not 
> affect the core
> >   object model.  Might also be useful as a way to overcome the
> >   TurbineUser/security tables problem that has confounded turbine
> >   users for years.
> >
> > I'm not sure why the object model in the referenced schema was left 
> > unaffected.  Moreover, I'm not sure why the deicion was made (4.5 
> > years
> > ago) not to uncomment the above package attribute line in 
> loadFromXML().
> >
> > I have played around with making that change to Table.java (and 
> > another one in Database.java to avoid setting the table's 
> package from 
> > the
> database)
> > to see what fallout there is from allowing a package attribute to 
> > table elements/objects.  Obviously the database.dtd must also be 
> > changed
> (trivial),
> > but there are some rather complex changes needed to the templates 
> > (Control.vm and Object.vm) to get the namespaces right on all 
> > referenced classes, to add additional import statements for 
> objects of 
> > these
> classes,
> > and to create new directory structures for additional namespaces.
> >
> > It still leaves me with what to do with the <DatabaseName>MapInit 
> > class which is generated from the database namespace, so 
> you have to 
> > declare
> >
> >   <database name="something" package="com.example.somwhere">
> >
> > to put the SomethingMapInit class (or let it use
> defaults--torque.generated,
> > I think).
> >
> > Anyway, I've been working off both the Torque trunks 
> modules as well 
> > the source tarball from 3.3-RC1--which are different and 
> seemingly not 
> > interchangeable.  If the rest of the Torque development community 
> > thinks this addition is a worthwhile endeavor, I have no problem 
> > fleshing out my changes some more (some of my Velocity 
> magic is pretty 
> > crufty right now) and submitting a patch.
> >
> > Certainly, if there are architectural reasons that this is 
> a BAD idea, 
> > I'd like to hear those as well.
> >
> >
> > Thank you,
> > Brendan
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-dev-help@db.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
> 
> 

Duke CE Privacy Statement
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-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message