ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Butler <jeffgbut...@gmail.com>
Subject Re: [VOTE] Should iBATIS support SQLJ?
Date Fri, 23 Jan 2009 23:16:11 GMT
Thanks Mario - the DB2 driver is in the plugin JAR.

I think precompiled packages are the only real benefit of SQLJ - and
they are often misunderstood by folks who haven't worked on enterprise
class databases.  So I'll grant you a benefit there.

What I'd like to see is some way to be able to add this to iBATIS as
an external tool, without having to include it in the base iBATIS
code.  That way we could see what the adoption rate is before we
commit to maintaining it as a part of the regular iBATIS code base.
It sounds like that may be easier to do with iBATIS3.

Is there some minimal change we could make to the iBATIS2 code to
allow you to supply this as a purely external tool?

Jeff Butler


On Fri, Jan 23, 2009 at 4:32 PM, Mario Ds Briggs
<mario.briggs@in.ibm.com> wrote:
> 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
>
> thanks
> Mario
>
>
>
>
>             Jeff Butler
>             <jeffgbutler@gmai
>             l.com>                                                     To
>                                       user-java@ibatis.apache.org
>             24/01/2009 02:52                                           cc
>
>                                                                   Subject
>             Please respond to         Re: [VOTE] Should iBATIS support
>             user-java@ibatis.         SQLJ?
>                apache.org
>
>
>
>
>
>
>
>
>
> 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>
> 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
>>
>
>
>

Mime
View raw message