The generator classes are very limited. AFAIK, you can only create an XML dump of all the data. You can't do application specific logic like creating an XML file that contains something like a forum definition record (from one table) plus all associated posts (from another table) and other information. This requires application specific knowledge that the generator classes do not support. This could be done via application specific code, but it is also possible for Torque to have the basic building blocks included to make such application specific coding easy. See: http://issues.apache.org/scarab/issues/id/TRQS344 <http://issues.apache.org/scarab/issues/id/TRQS344> for my take on these export building blocks. Also, when you go to import data into a different database, there will be application issues related to forgeign keys that need to be resolved. For example, importing a forum record that has a category forgeign key column from the old DB. This will need to be modified by the application specific code to point to the correct category key in the new database. Torque could support this by having Runtime code that will take XML and convert it into record objects that application code can then modify them as needed.
FWIW, I looked briefly at the ddlutils but they have yet to produce a release version and the project does not seem to be very active. Plus they currently don't have the functionality I'm trying to add to Torque. Maybe in the future but... Since I had some work time that I could allocate to this and nobody seemed to have strong opinions (or I just confused the heck out of everyone 8) ), I opted for the path of least effect on existing code. Rather than change DTD output, which might cause existing code to break, the patch I submitted in scarab only adds the JavaName to the Table and Column map files that are generated. ________________________________ From: Thomas Fischer [mailto:[EMAIL PROTECTED] Sent: Sat 1/28/2006 11:13 AM To: Apache Torque Developers List Subject: Re: Table and Column name mapping issues Can you shed some light on why you can not use the generator classes for this ? I have never tried to create a wrapper class around an ant task, but I would not think this is too difficult. I would object to have code for creating xml from database rows in two places in Torque. We do not even manage to get it right in the generator (Date stuff, Blob content etc. all causes problems). You for yourself are free to do what you want, obviously. You might also want to look at the ddlutils (db.apache.org/ddlutils) project. They also have code for generating XML out of database data. Apart from that, I do not see a compelling reason why Java names should be used in the xml rather than sql column names. A generator option to change this would be ok with me. Also, storing information about the java names in the Database map would also be ok with me, if you cared to implement it. Maybe it can be used for other stuff (some people might want to use reflection (shudder...)) Thomas On Mon, 23 Jan 2006, Greg Monroe wrote: > I'm trying to create some generic RUNTIME code which would > allow records to be imported/exported using the DTD format > that generator task creates. The thought is that in solving a > need we have here (moving stuff from staging to production > DBs), I might be able to have some generic runtime XML > Export/Import code to add to Torque. E.g., export based > on a criteria with all related foreign key table records too. > > However, I've found some interesting name mapping problems > in trying to do this. I'll open a issue and include a patch, but > before starting I thought I'd poll folks for what the "right" way > to fix this is. > > The basic problem is that the DTD uses the JavaName conventions > for table and columns names but the Map classes use the SQL > names. So how do you dynamically create an export record since > the JavaName information from the Schema XML does not seem > to be carried over into the runtime environment? > > There seem to be two choices to deal with this. The first is to > modify the DTD Generator task to allow for SQL names. Maybe > just simply adding a option flag here. This seems simple but > you end up with two DTD which describe the same set of data > and the possiblity of tag and/or attribute names that don't meet > the XML specs. > > The second is to change the Mapping classes to store both the > JavaName info and the SQL info. This is more complex because > it involves the templates and the base classes. On the other > hand, it would end up making the Map classes a more flexible. > > So, which approach (or is there one I missed) do folks think > would work best? > > TIA. > > Greg > > > Greg Monroe <[EMAIL PROTECTED]> (919)680-5050 > C&IS Solutions Team Lead > Duke Corporate Education, Inc. > 333 Liggett St. > Durham, NC 27701 > > > > Duke CE Privacy Statement > Please be advised that this e-mail and any files transmitted with it are > confidential communication or may otherwise be privileged or confidential and > are intended solely for the individual or entity to whom they are addressed. > If you are not the intended recipient you may not rely on the contents of > this email or any attachments, and we ask that you please not read, copy or > retransmit this communication, but reply to the sender and destroy the email, > its contents, and all copies thereof immediately. Any unauthorized > dissemination, distribution or copying of this communication is strictly > prohibited. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
