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-06 07:04 ------- > That is exactly my point, I wouldn't do it (the nesting). But I need it, and I have to do it somewhere, and as I try to explain, it's best to do it in the data extraction. :-) > We keep on adding more and more things to the <sql> task > and creating a monolithic monster (not you but over time). The fact is that here it's the easiest place to put things. What I could do is to make the SQLExtractor interface, and have the SQL task use that if defined. In this way we would keep the sql stuff in the same place but have pluggable extractors (maybe even a velocity extractor for templating). <sql blah blah> <extractor class="org.blik.MyExtractor"> <param name="nesting" value="2"/> </extractor> </sql> > Maybe we should move any (nw query functionality) to a separate > task e.g., <sqlquery/> defined to extract data from the DB > and leave <sql> mostly for ddl,dml operations. I think this would confuse users, and for it I woul dhave to replicate code from the sql task or do some refactoring. > Then we probably can have a better definition for it. As? Sorry, but I don't have time to think about this too much. If you can give me a more detailed explanation of how you would like to see this, I could find some time to do it, or else I'll jsut factor out the extractor. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
