On Mon, Feb 12, 2007 at 01:10:18PM +0100, Thomas Fischer wrote: > 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)
Yep, only requires a change to the DTD and two one-liners to Database.java and Table.java (unless further testing uncovers more). > - adding the logic to the templates to get the imports correct > Do you see any other places where changes must be made ? I haven't yet. To be honest the template changes were a little more invasive than I would have liked, so I may rethink them to see if there's an easier way. Obviously the main Control.vm template where it sets up paths and packages for everything had to do that within a foreach table loop instead in the outside database loop. The way I have it functioning right now it's a little hard to read (IMO). I'll see if I can clean it up and submit a patch for review. > 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. Okay, that's what I thought as well, and how I left it working. > 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 ? I was aware of those settings, although I do not use them. Coincidentally, the subpackage namespaces are appended to the table package namespace in the normal fashion. I think that Torque mostly has this [table package] feature already--finishing it mostly revolves around setting the package on each table, and making sure that when a package name or directory structure is needed that it is retrieved from the table in all cases, not the database. In any case, I set up torque.subpackage.base = base torque.subpackage.peer = peer torque.subpackage.map = mymap in my properties file and all the classes were generated beneath the namespace I had specified as the table pacakge attribute. Sweet. > 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. Yes, it does look as if Torque 3.3 is nearing completion. If I were to submit a patch, what should I use as my base? (I'm not sure an 3.3-RC[12] patch will apply against the trunk--maybe it will.) Brendan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
