ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Zabel <...@ezabel.com>
Subject Re: inline map format: empty String in nullValue
Date Sun, 10 Aug 2008 00:46:48 GMT
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 reasoning on removing the  
nullValue mapping as an attribute, though. Java supports primitives  
natively. If this were Ruby and everything was an object, I could see  
your point of view more easily. I guess I subscribe to the (old?)  
school of thought that an API offering mapping of sql to objects  
should support the full features of the language. But, I could  
probably be persuaded otherwise.

Oh, and good point about the TypeHandlers. Hadn't thought of that as a  
solution. (I hadn't read your email before I sent mine). That does  
seem to be a bit of an "arguable hack" though. If primitives aren't  
fully supported by an API, I'd feel better about not using them.

I'm for improving the API, even if it makes it /completely/  
incompatible with the current one. I also do Rails work, and I'm  
always wishing ActiveRecord were possible in Java. Definitely excited  
to see where iBATIS 3 takes us!


Ian.


On Aug 9, 2008, at 8:10 PM, Clinton Begin wrote:

> >> 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 fact, as a testament to iBATIS 3's committment to  
> maintaining our core values, the first thing I did was wrote a  
> compatibility kit:
>
> http://svn.apache.org/repos/asf/ibatis/trunk/java/ibatis-3/
>
> core == the engine.  compat == the ibatis-2 backward compatibility  
> kit.  I'm not sure if the compatibility kit will ever be recommended  
> in production over the real iBATIS 2.x implementation, but it shows  
> that we do support everything except those two features which we've  
> explicitly chosed to remove.  Primarily the compatibility kit is  
> used for testing.
>
> However, we WILL continue to advance the iBATIS API.  If you want my  
> honest opinion, the iBATIS 2.x API sucks.  It's old and crusty.  As  
> its original creator, I can't stand it.  It's verbose, string ridden  
> and loose.  For the last three years I've been working with .NET and  
> Rails, and I've learned a lot.  I'm hoping to bring a new paradigm  
> into the Java community with iBATIS 3, just like I did when I  
> released iBATIS 1.0.  What I will NOT do is:
>
>   * I will not make iBATIS an ORM.  That would be a silly waste my  
> time.  I'd rather go make money or play with my kids.  Hibernate  
> owns that space, they always will, and so they should!  Hibernate is  
> a kick ass ORM.
>
>   * I will not make iBATIS 3 just like iBATIS 2.  It will be  
> different.  Why?  Because you already have iBATIS 2.  Again, there  
> are better things to do than code something that already exists.
>
> Finally, I don't know why you ignored my statement about the  
> TypeHandler.  It's quite easy to add that to a typehandler,  
> especially with iB3. You can easily write it up and override the  
> default primitive handlers.  If it is useful enough for everyone,  
> submit it as a patch and then we can include it in the core.
>
> public class NonNullableTypeHandler {
>  public void setParameter(PreparedStatement ps, int i, Object  
> parameter, JdbcType jdbcType)
>      throws SQLException {
>    //if parameter == SOME_CONSTANT, send NULL, otherwise send  
> parameter.
>  }
>  public Object getResult(ResultSet rs, String columnName)
>      throws SQLException {
>    //if result == NULL, return SOME_CONSTANT, otherwise return result.
>  }
>  public Object getResult(CallableStatement cs, int columnIndex)
>      throws SQLException  {
>    //if result == NULL, return  SOME_CONSTANT, otherwise return  
> result.
>  }
> }
>
> That does EXACTLY what nullValue="SOME_CONSTANT" would do.  But it's  
> far cleaner and can be easily implemented in minutes.  It's also way  
> more flexible so you can handle more interesting cases.
>
> Cheers,
> Clinton


Mime
View raw message