ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ds Briggs <mario.bri...@in.ibm.com>
Subject Re: [VOTE] Should iBATIS support SQLJ?
Date Fri, 23 Jan 2009 22:32:09 GMT
thanks Jeff for going through the code.

Your explanation of the contributed source is correct.

So you still have to have JDBC setup
SQLJ and JDBC are not mutually exclusive. In fact both share the same
'java.sql.Connection' among other things. The SQLJ API itself allows you to
mix and match and move from one to the other on request.

This seems like an unusual work flow to me.  What's the benefit?
SQLJ is embedded SQL in java. (equivalent in C, would be like Pro C). The
number one benefit to the people who use it is basically similar to many of
the reasons folks use Stored Procedures. It gives you precompiled SQL
statements on the DB Server side. The added benefits are that the DBA can
control the execution plan completely, upgrade the exec plan as and when
required etc. Most of the people i know of who use it in production, find
it very beneficial for scenarios where there are tight SLA's around
response time for SQL execution. The control over the execution plan helps
them. Additional benefits including knowing exactly which SQL's came from
which application, database schema evolution etc. [ I will let the folks
who voted +5 add things they see beneficial]

Given the embedded nature, if you are using SQLJ and have queries created
on the fly in the app (e.g. search) you have to fall back to JDBC for this.
That explains the fallback to JDBC when dynamic elements are present.  I
hope the work flow is now explained. If you still have doubts or there are
parts i missed to explain, i certainly will. [In the contributed code it
also falls back when it couldnt find a implementation of a SQL in the
generated SQLJ.  This choice is open for discussion, we were covering the
scenario where someone updated the ibatis.xml but didnt regenarate SQLJ]

>From our side, point 1 you mentioned was important. People who picked
ibatis certainly were driven by its API and mapping. That doesnt change
even for the folks who want SQLJ in certain scenarios.

The DB2 driver, if it is there is an error. I will cross check


             Jeff Butler                                                   
             l.com>                                                     To 
             24/01/2009 02:52                                           cc 
             Please respond to         Re: [VOTE] Should iBATIS support    
             user-java@ibatis.         SQLJ?                               

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 <clinton.begin@gmail.com>
> 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

View raw message