(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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
