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]

Reply via email to