>> 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 On Sat, Aug 9, 2008 at 4:53 PM, Ian Zabel <[EMAIL PROTECTED]> wrote: > > 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 seems that iBATIS 3 is moving away from the idea of a true Data Mapper, and adopting a more ORM slant. I've seen it mentioned a few times that the developers prefer using objects over primitives. This seems to be a personal preference, as far as I can tell. I think personal preference is usually a good thing when it comes to code. Trying to be a jack-of-all trades can really dilute best practices. > > 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. Sometimes, this is the best solution; especially when it comes to legacy applications. > > Developers will simply have to make a choice. Either stick with iBATIS 2, retrofit a lot of code to match the new ideals of iBATIS 3, or use iBATIS 3 in a non-standard, arguably hacky way. > > I wish we didn't have to make this choice, but sometimes that's the price of progress. :) > > Ian. > > > On Aug 9, 2008, at 6:08 PM, John Clash wrote: > >> >> 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 quite much. >> >> Can we expect some substitute for this in iBatis 3? >> >> Ondra >> >> >> >> Clinton Begin wrote: >>> >>> 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 >>> >> >> -- >> View this message in context: http://www.nabble.com/inline-map-format%3A-empty-String-in-nullValue-tp18905940p18908933.html >> Sent from the iBATIS - User - Java mailing list archive at Nabble.com. >> >
