If it's important enough, what we'll end up doing is including it as a
standard set of type handlers or part of the existing type handlers. For
example, if using the non-null typehandler option, it can set some standard
NULL_VALUE constant for the primitive (MIN_VALUE for integers, NaN for
floats,
Hi Clinton,
Clinton Begin wrote:
>
> [...] but it shows that we do support everything except those two features
> ...
>
Hmmm... thankfully :-)
Clinton Begin wrote:
>
> ... which we've explicitly chosed to remove. Primarily the compatibility
> kit is used for testing. [...]
>
> If it is u
Clinton,
Good to read your point of view here. It's very much appreciated.
I wasn't aware of the compatibility kit for iBATIS 3. Also wasn't
aware that the only incompatible changes are the nullValue mapping and
XML. This is good to know.
I honestly can't say I really understand the reason
Hi Ian,
Ian Zabel-3 wrote:
>
> However, to many people, I believe iBATIS represents a low(er) level
> tool (than Hibernate, JPA, etc) that allows them to really get their
> SQL mapped up to their objects without having to worry about best
> practices.
>
True. Personally I use iBatis toge
Clinton Begin wrote:
>
> You can also make your own type handlers for string and integer that
> always yield some default value instead of null.
>
Just to clear things out:
1) I use nullValue in INSERT to convert empty String to NULL, what performs
faster and keeps better semantics.
2) nullV
>> It seems that iBATIS 3 is moving away from the idea of a true Data
Mapper, and adopting a more ORM slant
Let's not start spreading rumors.
This is simply not the case. iBATIS 3 will offer everything iBATIS 2
supports except mapping directly to XML and nullValue mapping *as an
attribute*. In
Ondra,
I agree. We are making use of this feature quite a bit in our legacy
system (old objects, old DB) in which we are currently switching to
use iBATIS. We are striving to maintain high compatibility by making
few changes to the code, sql, and schema. nullValue comes in handy a
LOT.
It's actually quite simple to fix... just don't use primitives. :-)
You can also make your own type handlers for string and integer that always
yield some default value instead of null.
Clinton
On Sat, Aug 9, 2008 at 4:08 PM, John Clash <[EMAIL PROTECTED]> wrote:
>
> Quite bad news for me :(
>
Quite bad news for me :(
I use nullValue as a convenient brief instrument to unify both null values
OR empty String to NULL in the database (e.g. when importing from Excel and
some cells are empty (that yields null) and some have empty strings).
Handling it in Java or SQL code would clutter it q
I recommend not using nullValue replacement. It's confusing and doesn't
work the way most people would expect it to, quite the opposite actually.
It's used to map nullable columns to non-nullable class members, like int,
long, double, boolean etc...
It will not be available in iBATIS 3.
Clinton
If i want to set a nullValue replacement for an empty String I use this in an
explicit parameterMap:
I want to do the same thing using inline parameters. I've tried the
following:
#street:VARCHAR:""#
#street:VARCHAR:#
#street,jdbcType=VARCHAR,nullValue=""#
#street,jdbcType=VARCHAR,nullValue=#
11 matches
Mail list logo
