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: inline map format: empty String in nullValue
Date Sun, 10 Aug 2008 01:42:45 GMT
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, "" for strings etc.)

If it's important enough, it will be included of course.  You as the
community will largely decide that.

My passion was only around the misunderstanding around the direction of
iBATIS.  nullVAlue is a pretty simple feature, but I feel it's messily
implemented in 2.x, as I do about a lot of things.

The iBATIS 3.0 Whiteboard discusses a lot of this, but it's only that -- a


The whiteboard is a brainstorm, and what actually happens will likely take a
bit of a different form.  But looking through the list, I think the most
important things that we'll tackle are (in priority order):

  * A simpler XML configuration.
        - Fewer and simpler EL based dynamic SQL tags
        - Far simpler cache configuration
        - Far simpler join mapping
        - Only inline parameters... (I haven't used a parameter map stanza
in years... you?)
        - Simpler and more reusable result maps
        - Smarter auto result mapping (auto map remaining, ignore missing,
and column/property translators)
        - Less verbosity and less type signature specification due to the
next point

  * Interface binding.
        - This was actually proposed for a future version of JDBC, but we
beat them to it in both the idea and the implementation.  :-)

  * Annotations configuration options.
        - Interfaces can be marked up with annotations to provide an even
simpler configuration option for simple interfaces.  You can decide to use
XML, Annotations or a combination.

  * An externalized Transaction Manager... mostly to get out of Spring's way
for those using Spring.

Things that are contentious and will likely either not be implemented or
will look somewhat different as described (or perhaps as an alternative API)

  * Conventional configuration
  * CRUD generation (this is where iBATIS starts to look ORMish -- but
IMHO...it's a silly dogmatic distinction... to iBATIS its just SQL you don't
have to write)
  * Smart SQL (SELECT) generators

iBATIS 3 has a more distinct core and a simpler Java API that will make it
possible to build new APIs on top of the core (even an ORM if someone were
so inclined).  So there may be some experimentation.  But our goal will
always be simplicity above all else.

On Sat, Aug 9, 2008 at 7:20 PM, John Clash <spam.trash@seznam.cz> wrote:

> 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 useful enough for everyone, submit it as a patch and then we can
> > include it in the core.
> >
> I think this "empty String <=> NULL" case can be considered as a must-have.
> It could be accessible using some alias, like with "map" for java.util.Map.
> Actually, besides "", I can't figure out other usage of nullValue, which
> would not be a DB design flaw, esp. with mentioned primitive numbers usage.
> Well, thanks for explanation.
> Ondra
> --
> View this message in context:
> http://www.nabble.com/inline-map-format%3A-empty-String-in-nullValue-tp18905940p18910022.html
>  Sent from the iBATIS - User - Java mailing list archive at Nabble.com.

View raw message