I took a quick look at the SQL code that was sent recently. Is this the proposed implementation? As far as I can tell, the proposed implementation takes an existing set of SqlMap files and translates them to SQLJ files. So the workflow is this:
1. Write iBATIS Sql maps 2. Generate SQLJ from those maps 3. Use the modified iBATIS JAR to execute *some*, and only *some* of that code with SQLJ rather than JDBC. The SQLJ executer will fallback to regular iBATIS (JDBC) if there is any dynamic element in an SQL map statement (and under some other conditions too - I can't remember exactly which right now). So you still have to have JDBC setup, the executor just switches to SQLJ for some of the statements. This seems like an unusual work flow to me. What's the benefit? Also, the code that was sent included the IBM DB2 driver, certainly not open source, and we have no legal right to redistribute. I don't know if that was required or was just included as a convenience. So, I'm -1 based on the implementation I've seen. Jeff Butler On Fri, Jan 23, 2009 at 1:05 PM, Clinton Begin <[email protected]> wrote: > Hi everyone, > > A group of developers have approached us with a contribution of code > to patch iBATIS so that it supports SQLJ. > > If you've never heard of SQLJ, here are two links... > > http://en.wikipedia.org/wiki/SQLJ > http://www.google.com/trends?q=sqlj > > The future of SQLJ is not clear to me, nor is its adoption rate over > time. Certainly iBATIS has a broader user base than SQLJ does. > > So the question is: Should we support SQLJ as a feature of iBATIS? > > +5 == Absolutely... iBATIS will be better for it. > +1 == Yes, support SQLJ. > 0 == Doesn't matter to me. > -1 == No, keep them separate. > -5 == No way. iBATIS is better off without it. > > This vote will remain open for 72 hours. > > Cheers, > Clinton >
