Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4927CD17.3010909@intland.com>
Date: Sat, 22 Nov 2008 10:12:55 +0100
From: Zsolt Koppany <zkoppanylist@intland.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: user-java@ibatis.apache.org
Subject: Re: ibatis & derby problem
References: <4923E726.2060305@intland.com>
	 <a10a823c0811190412x19176daatc7e6025367e75427@mail.gmail.com>
 <16178eb10811190620j136b4379sad0e69a8959b0cd@mail.gmail.com>
In-Reply-To: <16178eb10811190620j136b4379sad0e69a8959b0cd@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I attached the answer from the derby list.

I just wonder how effective the communication is between the derby and 
ibatis communities.

Would it be really so complicated to fix the problem? Discussions about 
standards are very important however the acceptance of API-s is more 
important, also for derby but also for ibatis.

I think ibatis is with hibernate one of the best (for me the best) java 
database mappers. Sun and IBM are pushing derby. The performance of 
derby is today much better than it was a couple of years ago.

Our persistence tests run 16 minutes with Oracle and 26 with derby (we 
use an old derby driver) and this results make derby more attractive 
because you just don't have the huge overhead of oracle (including the 
installation problems).

Zsolt

Here is the answer from the derby list:

Bernt M. Johnsen schrieb:
 >>>>>>>>>>>>> Zsolt Koppany wrote (2008-11-21 09:42:51):
 >> Kathey,
 >>
 >> How can you always know the type of an Object? Ibatis supports also
 >> jdbc<-->java.util.Map mapping. How do you want to know for example 
if a
 >> value is not available in the Map which java type to use to set NULL?
 >>
 >> ps.setNull(1,java.sql.Types.VARCHAR);
 >>
 >> It might be a weakness of the JDBC specification (what I don't know) 
but
 >> our application runs for years with mysql-4.x, mysql-5, Postgress,
 >> Oracle-9 and Oracle-10. These are well known stable and good databases.
 >>
 >> Ibatis is very popular API and I'm suprised that derby doesn't well
 >> support this very useful and easy to use API.
 >
 > It could be turned the other way around: "I'm surprised that Ibatis
 > does not adhere to the JDBC standard".
 >
 > I think (and more with me) that what Derby does as in accordance with
 > the JDBC specification (I think it was thoroughly discussed on the
 > derby-dev list a year or two ago), and that MySQL,PostgreSQL and
 > Oracle has implemented something which might be interpreted as an
 > extension of the JDBC standard or just plain wrong.
 >
 > A tool like Ibatis should *not* utilize non-standard extensions
 > because that might cause portability problems, like you just
 > experienced.
 >
 >


Clinton Begin schrieb:
> 
> Yeah, this time you have to blame Derby... While Larry is right and this 
> is a very silly API... Derby was wrong to allow setting NULL without 
> specifying the type, and unfortunately you got caught using their 
> non-standard API.
> 
> Funny how the "Java DB" is non-standard.  :-)
> 
> But then again, it just wouldn't be Sun if this stuff made any sense at 
> all...
> 
> Clinton
> 
> 
> On Wed, Nov 19, 2008 at 5:12 AM, Larry Meadors <larry.meadors@gmail.com 
> <mailto:larry.meadors@gmail.com>> wrote:
> 
>     This is not really an issue with ibatis, it's a SQLException thrown
>     back by the driver. We can't fix that, just like we can't fix it with
>     Oracle (which does the same thing).
> 
>     This has always seemed like a totally retarded thing to me - I mean,
>     come on JDBC, it's NULL. It's not like I'm trying to stuff "fred" into
>     an integer field. NULL doesn't really have a type, so why is the
>     method signature like this:
> 
>     void setNull(int parameterIndex, int sqlType); // this is from
>     PreparedStatement
> 
>     So, you'll have to pick one of these options:
>     1) use a different driver
>     2) look for a way to make derby allow that
>     3) patch ibatis to provide that (if it can)
> 
>     Option #3 would make this less painful in *some* cases (only where you
>     are using beans and not maps) and you would have to make an attempt to
>     infer the SQL type based on the java type of the property being mapped
>     as reported by the bean.
> 
>     To be honest, I have never looked into doing this because it seemed
>     like more work than adding :VARCHAR to the nullables in my apps. If
>     you want to try it, please do - and attach the changed files to a JIRA
>     issue. We'll see if we can get it into the next 2.x release, and also
>     3.x. :-D
> 
>     Larry
> 
> 
>     On Wed, Nov 19, 2008 at 3:15 AM, Zsolt Koppany
>     <zkoppanylist@intland.com <mailto:zkoppanylist@intland.com>> wrote:
>      > with all newer derby versions I get an Exception if I want to
>     store NULL
>      > values.
>      >
>      > Derby (or ibatis) wants my application telling also the java type
>     of the
>      > NULL value something like below:
>      >
>      > #value:INTEGER#
>      >
>      > We cannot modify all ibatis files and additional we should write
>     a lot of
>      > new tests testing all possible NULL values.
>      >
>      > We use ibatis-2.3.4.726.
>      >
>      > How can we fix the problem?
>      >
> 
>