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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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?
>
