ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject Re: ibatis & derby problem
Date Sun, 23 Nov 2008 16:23:49 GMT
I believe Bernt misunderstood your question and didn't fully understand the
details.

  * The problem is that Derby *used* to be in non-compliant with the JDBC
spec.
  * You used it while it wasn't compliant.
  * When you upgraded to the new compliant driver, you got screwed.

While Derby may be compliant now (as Bernt believes based on his response),
it was not always compliant.

So now both iBATIS and Derby are compliant, and the only thing remaining out
of compliance is your app.  It's unfortunate, but iBATIS can't do anything
to correct JDBC drivers that are or *were* non-compliant.

Cheers,
Clinton

On Sat, Nov 22, 2008 at 2:12 AM, Zsolt Koppany <zkoppanylist@intland.com>wrote:

> 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?
>>     >
>>
>>
>>

Mime
View raw message