You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Clinton Begin <cl...@gmail.com> on 2009/01/23 20:05:28 UTC
[VOTE] Should iBATIS support SQLJ?
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
Re: [VOTE] Should iBATIS support SQLJ?
Posted by prakashtgt <pr...@target.com>.
+5
I vote +5 for this. We are looking forward to use SQLJ in our enterprise
application.
Jeff Butler-2 wrote:
>
> 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 <cl...@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
>>
>
>
--
View this message in context: http://www.nabble.com/-VOTE--Should-iBATIS-support-SQLJ--tp21630802p21679762.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
Thanks Jeff. Are you referring to 'org.ibatis.sqlj.ui_1.0.0.jar' on the
JIRA as plugin JAR. I cross checked that, it doesnt contain it. (You are
probably referring to the post on the user group where we made it available
for the Prakash from Target - yes it was an error. Is there a way i can
remove it from Nabble)
I am game for your offer of supporting it as an external tool. So going by
Clinton, it looks like in ib3 that will possible. For ib2, we probably did
that when we started out, but its too long back for me to remember. We will
come up with a proposal for what the minimal refactoring is required in ib2
to support this externally without heartburn to both sides.
BTW ib3 is a totally different code base right ?
thanks
Mario
Jeff Butler
<jeffgbutler@gmai
l.com> To
user-java@ibatis.apache.org
24/01/2009 04:46 cc
Subject
Please respond to Re: [VOTE] Should iBATIS support
user-java@ibatis. SQLJ?
apache.org
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
<ma...@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 <cl...@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
>>
>
>
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Jeff Butler <je...@gmail.com>.
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
<ma...@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 <cl...@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
>>
>
>
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
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 <cl...@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
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Jeff Butler <je...@gmail.com>.
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 <cl...@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
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Nicholoz Koka Kiknadze <ki...@gmail.com>.
0 == Doesn't matter to me
Absolutely
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Ian Zabel <ia...@ezabel.com>.
0
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Jeff Stahl <je...@earthlink.net>.
+5 - Definitely.
I'd vote higher, as SQLJ support is long overdue for open source DBs,
but the sooner the better.
Perfect, and thank you for getting on this.
Jeff Stahl
Clinton Begin 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
>
>
Re: Unsubscribe
Posted by Larry Meadors <la...@gmail.com>.
Please read: http://ibatis.apache.org/mailinglists.html
Larry
Unsubscribe
Posted by Westgård Trond <tr...@imr.no>.
-----Opprinnelig melding-----
Fra: Hemant.Kamatgi [mailto:Hemant.Kamatgi@target.com]
Sendt: 24. januar 2009 01:04
Til: user-java@ibatis.apache.org
Emne: RE: [VOTE] Should iBATIS support SQLJ?
-1
-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: Saturday, January 24, 2009 12:35 AM
To: iBatis Java Mail List
Subject: [VOTE] Should iBATIS support SQLJ?
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
RE: [VOTE] Should iBATIS support SQLJ?
Posted by "Hemant.Kamatgi" <He...@target.com>.
-1
-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: Saturday, January 24, 2009 12:35 AM
To: iBatis Java Mail List
Subject: [VOTE] Should iBATIS support SQLJ?
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
RE: [VOTE] Should iBATIS support SQLJ?
Posted by "Barnes, Jim D" <Ji...@ps.net>.
-1
-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: Friday, January 23, 2009 1:05 PM
To: iBatis Java Mail List
Subject: [VOTE] Should iBATIS support SQLJ?
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
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Thomas Duffey <td...@utilivisor.com>.
-1
On Jan 23, 2009, at 1:05 PM, Clinton Begin 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
RE: [VOTE] Should iBATIS support SQLJ?
Posted by "Grigoras, Vasile" <vg...@Infomedics.com>.
+1
-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: Friday, January 23, 2009 2:05 PM
To: iBatis Java Mail List
Subject: [VOTE] Should iBATIS support SQLJ?
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
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Larry Meadors <la...@gmail.com>.
Urhm, +1 on that...still -5 on the SQLJ support. :-P
Larry
On Fri, Jan 23, 2009 at 1:56 PM, Clinton Begin <cl...@gmail.com> wrote:
> I suppose we should count all of the misinterpretations about "what
> SQLJ is" as "no". ;-)
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Clinton Begin <cl...@gmail.com>.
I suppose we should count all of the misinterpretations about "what
SQLJ is" as "no". ;-)
Clinton
On Fri, Jan 23, 2009 at 1:45 PM, Larry Meadors <la...@gmail.com> wrote:
> As a clarification, SQLJ is NOT a database or even an API.
>
> It is a Java language extension.
>
> Larry
>
>
> On Fri, Jan 23, 2009 at 1:39 PM, Sundar Sankar <fa...@gmail.com> wrote:
>> +1. Support to all databases is definitely a great plus to have.
>>
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Larry Meadors <la...@gmail.com>.
As a clarification, SQLJ is NOT a database or even an API.
It is a Java language extension.
Larry
On Fri, Jan 23, 2009 at 1:39 PM, Sundar Sankar <fa...@gmail.com> wrote:
> +1. Support to all databases is definitely a great plus to have.
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Sundar Sankar <fa...@gmail.com>.
+1. Support to all databases is definitely a great plus to have.
-Sundar
On Fri, Jan 23, 2009 at 12:05 PM, Clinton Begin <cl...@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
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Zhubin Salehi <zh...@yahoo.com>.
0
Clinton Begin 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
>
>
--
View this message in context: http://www.nabble.com/-VOTE--Should-iBATIS-support-SQLJ--tp21630802p21668587.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Giovanni Cuccu <gi...@gmail.com>.
-1
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Clinton Begin <cl...@gmail.com>.
RE: iB3... It definitely will, as you can override the configuration
class entirely.
On Fri, Jan 23, 2009 at 2:09 PM, Brandon Goodin
<br...@gmail.com> wrote:
> -5
>
> I appreciate the work that was put into providing this patch. However, it
> would be best not to introduce this as a maintenance overhead for the iBatis
> code base. SQLJ is not very popular at all. It also does not appear across
> languages like SQL does. It would be nice if our architecture supported the
> ability to add these type of extensions so that those who find it useful can
> take advantage of it. Perhaps iB3 will provide the needed hooks to write a
> SQLJ plugin/extension.
>
> Brandon Goodin
>
>
> On Fri, Jan 23, 2009 at 1:05 PM, Clinton Begin <cl...@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
>
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
thanks for the appreciation. FWIW we will provide the maintenance.
Brandon Goodin
<brandon.goodin@g
mail.com> To
user-java@ibatis.apache.org
24/01/2009 02:39 cc
Subject
Please respond to Re: [VOTE] Should iBATIS support
user-java@ibatis. SQLJ?
apache.org
-5
I appreciate the work that was put into providing this patch. However, it
would be best not to introduce this as a maintenance overhead for the
iBatis code base. SQLJ is not very popular at all. It also does not appear
across languages like SQL does. It would be nice if our architecture
supported the ability to add these type of extensions so that those who
find it useful can take advantage of it. Perhaps iB3 will provide the
needed hooks to write a SQLJ plugin/extension.
Brandon Goodin
On Fri, Jan 23, 2009 at 1:05 PM, Clinton Begin <cl...@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
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Brandon Goodin <br...@gmail.com>.
-5
I appreciate the work that was put into providing this patch. However, it
would be best not to introduce this as a maintenance overhead for the iBatis
code base. SQLJ is not very popular at all. It also does not appear across
languages like SQL does. It would be nice if our architecture supported the
ability to add these type of extensions so that those who find it useful can
take advantage of it. Perhaps iB3 will provide the needed hooks to write a
SQLJ plugin/extension.
Brandon Goodin
On Fri, Jan 23, 2009 at 1:05 PM, Clinton Begin <cl...@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
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Jan Kriesten <kr...@mail.footprint.de>.
> -1 == No, keep them separate.
Regards, --- Jan.
RE: [VOTE] Should iBATIS support SQLJ?
Posted by "Prakash.Govindrao" <Pr...@target.com>.
+5
-----Original Message-----
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: Friday, January 23, 2009 1:05 PM
To: iBatis Java Mail List
Subject: [VOTE] Should iBATIS support SQLJ?
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
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Reuben Firmin <re...@benetech.org>.
-1
On Fri, Jan 23, 2009 at 2:05 PM, Clinton Begin <cl...@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
>
Re: [RESULT] Should iBATIS support SQLJ?
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
thanks clinton. Graciously accepted.
>>
We welcome the contributors to either find a way to add this support
without modifying the iBATIS source code.
<<
Assumed following Jeff's suggestion, a simple 'Executor' registration
mechanism is acceptable.
thanks
Mario
Clinton Begin
<clinton.begin@gm
ail.com> To
iBatis Java Mail List
27/01/2009 04:19 <us...@ibatis.apache.org>
cc
Please respond to Subject
user-java@ibatis. [RESULT] Should iBATIS support
apache.org SQLJ?
The vote to officially accept the contribution of SQLJ support to the
core iBATIS source base has failed.
* A quick count count of all votes (unofficial, but conclusive;
binding and non-binding) yields:
- 5 votes for,
- 5 votes impartial, and
- 10 votes against.
* Two votes in favor can be counted from the contributors.
* All binding votes were against.
It is clear that the community does not show a great deal of support
for SQLJ, nor do the committers, thus iBATIS will not officially
support SQLJ. iBATIS 2.x development has stabilized to maintenance
only. Thus we do not expect further major changes or features to be
introduced, as development of iBATIS 3.0 nears Alpha stage.
We welcome the contributors to either find a way to add this support
without modifying the iBATIS source code, or by forking the source and
maintaining their own parallel release.
Best regards,
Clinton Begin
On Fri, Jan 23, 2009 at 12:05 PM, Clinton Begin <cl...@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
>
[RESULT] Should iBATIS support SQLJ?
Posted by Clinton Begin <cl...@gmail.com>.
The vote to officially accept the contribution of SQLJ support to the
core iBATIS source base has failed.
* A quick count count of all votes (unofficial, but conclusive;
binding and non-binding) yields:
- 5 votes for,
- 5 votes impartial, and
- 10 votes against.
* Two votes in favor can be counted from the contributors.
* All binding votes were against.
It is clear that the community does not show a great deal of support
for SQLJ, nor do the committers, thus iBATIS will not officially
support SQLJ. iBATIS 2.x development has stabilized to maintenance
only. Thus we do not expect further major changes or features to be
introduced, as development of iBATIS 3.0 nears Alpha stage.
We welcome the contributors to either find a way to add this support
without modifying the iBATIS source code, or by forking the source and
maintaining their own parallel release.
Best regards,
Clinton Begin
On Fri, Jan 23, 2009 at 12:05 PM, Clinton Begin <cl...@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
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Larry Meadors <la...@gmail.com>.
-5
IMO, this is a dying technology.
Larry
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Kai Grabfelder <no...@kaigrabfelder.de>.
0, doesn't matter to me
--- Original Nachricht ---
Absender: Clinton Begin
Datum: 23.01.2009 20:05
> 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
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Jiming Liu <ji...@gmail.com>.
-5, it is a dying technology.
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
We see it as 'iBATIS uses JDBC', 'iBATIS can also use SQLJ'
Mario
Clinton Begin
<clinton.begin@gm
ail.com> To
user-java@ibatis.apache.org
27/01/2009 04:05 cc
Subject
Please respond to Re: [VOTE] Should iBATIS support
user-java@ibatis. SQLJ?
apache.org
The only problem I have with this logic is that we could add a LOT to
iBATIS that wouldn't impact our users. The question is not "can", the
question is "should".
SQLJ was one of the technologies that was available when I started
iBATIS, and it wasn't good enough. Since then iBATIS has earned
significantly more users and has achieved greater market penetration
than SQLJ. It can be said that this success is directly related not
only to what iBATIS *is*, but also to what it is *not*.
I believe the only reason iBATIS has survived where other ORMs have
not (in the wake of Hibernate's dominance) is that it's different.
Different from ORM, different from JDBC, different from SQLJ....
iBATIS is unique. To add something like SQLJ to iBATIS would take
away from what iBATIS is.
Therefore, I'll now cast my vote:
-5
Cheers,
Clinton
On Mon, Jan 26, 2009 at 3:11 PM, <Ch...@sybase.com> wrote:
>
> 0
>
> IF it doesn't impact the main code line and someone is willing to
maintain
> it, then why not? Seems more like a plugin at this rate.
>
> Chris Mathrusse
> christopher.mathrusse@sybase.com
> Sybase, Inc
> One Sybase Drive
> Dublin, CA 94568
> (925) 236-5553
>
>
> Clinton Begin <cl...@gmail.com>
>
> 01/23/2009 11:05 AM
>
> Please respond to
> user-java@ibatis.apache.org
> To
> iBatis Java Mail List <us...@ibatis.apache.org>
> cc
> Subject
> [VOTE] Should iBATIS support SQLJ?
>
>
>
>
> 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
>
>
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Clinton Begin <cl...@gmail.com>.
The only problem I have with this logic is that we could add a LOT to
iBATIS that wouldn't impact our users. The question is not "can", the
question is "should".
SQLJ was one of the technologies that was available when I started
iBATIS, and it wasn't good enough. Since then iBATIS has earned
significantly more users and has achieved greater market penetration
than SQLJ. It can be said that this success is directly related not
only to what iBATIS *is*, but also to what it is *not*.
I believe the only reason iBATIS has survived where other ORMs have
not (in the wake of Hibernate's dominance) is that it's different.
Different from ORM, different from JDBC, different from SQLJ....
iBATIS is unique. To add something like SQLJ to iBATIS would take
away from what iBATIS is.
Therefore, I'll now cast my vote:
-5
Cheers,
Clinton
On Mon, Jan 26, 2009 at 3:11 PM, <Ch...@sybase.com> wrote:
>
> 0
>
> IF it doesn't impact the main code line and someone is willing to maintain
> it, then why not? Seems more like a plugin at this rate.
>
> Chris Mathrusse
> christopher.mathrusse@sybase.com
> Sybase, Inc
> One Sybase Drive
> Dublin, CA 94568
> (925) 236-5553
>
>
> Clinton Begin <cl...@gmail.com>
>
> 01/23/2009 11:05 AM
>
> Please respond to
> user-java@ibatis.apache.org
> To
> iBatis Java Mail List <us...@ibatis.apache.org>
> cc
> Subject
> [VOTE] Should iBATIS support SQLJ?
>
>
>
>
> 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
>
>
>
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Zoran Avtarovski <zo...@sparecreative.com>.
Apologies for being late. It was a long weekend down here.
0
I agree it¹s a dying technology, but if the contributors are willing to
maintain it and it won¹t affect performance for non SQLJ implementations...
Z.
>
> 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
Re: [VOTE] Should iBATIS support SQLJ?
Posted by "C.F-Win in China F" <we...@gmail.com>.
-5
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
Since the comments that folks are mentioning while voting is regards to the
whether this is dying technology or not, it is appropriate to share the
contributing group's thought on this.
The contributors are not bothered if this dying technology, resurrecting
technology or anything else. That is missing the point. Jeff Butler hit the
nail on the head about the benefit of precompiled packages for enterprise
classes of databases. The contributors feel that if you have that
requirement, it shouldnt mean that you should miss out of using frameworks
like iBatis, Spring etc. The contributors are aware of a few situations
where users faced this EITHER OR choice and the goal is to ensure it doesnt
have to be a EITHER OR choice anymore.
thanks
Mario
Mario Ds
Briggs/India/IBM@
IBMIN To
user-java@ibatis.apache.org
24/01/2009 06:11 cc
iBatis Java Mail List
<us...@ibatis.apache.org>
Please respond to Subject
user-java@ibatis. Re: [VOTE] Should iBATIS support
apache.org SQLJ?
While i agreed to Jeff's request of seeing how this can be externalized
with some minimal refactoring to ibatis 2, FWIW i still thought it is fair
to the ibatis users/community (especially those who dont know anything
about SQLJ which one can safely assume is the majority) about what this
patch means, since folks are still voting...
1- Absolutely no change to the way you build and use ibatis applications.
You wont see/feel anything change.
2 - There wont even be an additional jar (SQLJ.jar) that will be forced
down your throat to download and keep on your machine or to satisfy
compile/runtime dependencies.
3- It is a simple 3 java files with no external dependencies that get added
to ibatis source code.
thanks
Mario
Clinton Begin
<clinton.begin@gm
ail.com> To
iBatis Java Mail List
24/01/2009 00:35 <us...@ibatis.apache.org>
cc
Please respond to Subject
user-java@ibatis. [VOTE] Should iBATIS support SQLJ?
apache.org
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
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
While i agreed to Jeff's request of seeing how this can be externalized
with some minimal refactoring to ibatis 2, FWIW i still thought it is fair
to the ibatis users/community (especially those who dont know anything
about SQLJ which one can safely assume is the majority) about what this
patch means, since folks are still voting...
1- Absolutely no change to the way you build and use ibatis applications.
You wont see/feel anything change.
2 - There wont even be an additional jar (SQLJ.jar) that will be forced
down your throat to download and keep on your machine or to satisfy
compile/runtime dependencies.
3- It is a simple 3 java files with no external dependencies that get added
to ibatis source code.
thanks
Mario
Clinton Begin
<clinton.begin@gm
ail.com> To
iBatis Java Mail List
24/01/2009 00:35 <us...@ibatis.apache.org>
cc
Please respond to Subject
user-java@ibatis. [VOTE] Should iBATIS support SQLJ?
apache.org
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
Re: [VOTE] Should iBATIS support SQLJ?
Posted by Ch...@sybase.com.
0
IF it doesn't impact the main code line and someone is willing to maintain
it, then why not? Seems more like a plugin at this rate.
Chris Mathrusse
christopher.mathrusse@sybase.com
Sybase, Inc
One Sybase Drive
Dublin, CA 94568
(925) 236-5553
Clinton Begin <cl...@gmail.com>
01/23/2009 11:05 AM
Please respond to
user-java@ibatis.apache.org
To
iBatis Java Mail List <us...@ibatis.apache.org>
cc
Subject
[VOTE] Should iBATIS support SQLJ?
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