db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject RE: package attribute on table?
Date Mon, 12 Feb 2007 12:10:18 GMT

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
/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.


"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
> 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"
>     <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
>   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
> to see what fallout there is from allowing a package attribute to table
> elements/objects.  Obviously the database.dtd must also be changed
> 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
> 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
> 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

View raw message