db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brendan Miller" <bmil...@dotster.com>
Subject package attribute on table?
Date Fri, 09 Feb 2007 20:17:01 GMT

(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() 

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

caused he generator to create


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 
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,

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

View raw message