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