DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28681>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28681 [PATCH] Xml output for the SQL task ------- Additional Comments From [EMAIL PROTECTED] 2004-05-07 08:35 ------- Thanks for your replies guys. I'm sorry I probably seemed as being pissed off (and in fact I was a little ;-), but I did not fully understand what you meaned in your comments. > In your current proposal, your nested XML output requires a certain order for > the query, in order for nesting to be processed correctly. So what does > happens if I have several queries in my <sql/>? Do they all are required to > look the same? Actually a need a certain order for the *output* of the query, not the query itself. I mean, I don't care how you do the query, but the query gives a table as a result, right? So I nest based on the first, second, third, etc columns of the resulting table, just like pivoting works in a spreadsheet. I thought that this would simplify it for the user (as it does for me), but probably it's better to have the user specify the column names to group by. > - If you want to be able to write generic extractors, (e.g., velocity) > then you need to be able to specify the velocity script which may be complex. I'd only add it as a file, and besides, it's part of the extractor code, not the sql one. > - If you want a scripted extractor, you may need to be able to include the > text of the script. ? Can't I jsut reference a file in the extractor part? > Something like: > <sql ....> > <transaction> > <extractor class="foo.my.Extractor"> > <formatter> > > </formatter> > <query> > select a, b from c, d where c.a = d.b > </query> > </extractor> > </transaction> > </sql> > > Now when you see all what is needed to do it properly, then it makes much > more > sence to use a separate task for all this. I'm still unconvinced, as the sql task already outputs CSV; but before commenting further I'll try to add the extractor to the SQL task and see how the code is, taking transactions into account. With that done, it will be easier for all to actually see it and decide. > Better to create a new task and only use well-characterized project-wide > patterns to hook SQLExec.java if necessary to nest the new result set > formatting task. That's the idea, probably I was not clear. I mean that I want to separate the <extractor> part outside of the <sql> taks, leaving just hooks that keep all the sql stuff in the sql task. > If it does not require hooks, then why not submit the formatter to > Ant-Contrib where it can comforatbly enter the tree in an underdesigned > first-cut state and evolve as one works out the requirements more fully? I would happily do it, but to be able to format while the sql task is running I need hooks. Thanks guys for keeping the replies coming, I'll see what I can do about this. :-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
