Comments on: iBatis – Mapping Database NULL

By: Kambiz

Kambiz — Fri, 05 Jun 2009 16:09:42 +0000

you could also modify the sql statement to get default values instead of null.

SELECT CASE
WHEN passwordExpired IS NULL THEN false
ELSE passwordExpired
END
FROM Employee;

By: Nick

Nick — Mon, 30 Mar 2009 20:41:26 +0000

Thanks for the comments.
Yes, using objects is another option although I’m not convinced the best. Of course it really depends on your database and design. Having an old legacy database where anything goes as far as type checking and so on, then I agree that objects may be a slightly more useful (not better) option.

By: Developer Dude

Developer Dude — Mon, 30 Mar 2009 19:28:13 +0000

Like Mauli, I would choose objects over primitives too because often a null value does have some meaning in an app (*gasp* – yeah, yeah, I know, it is heresy, but this is the real world after all, and even Date said null means the value is unknown – IIRC).

However, it is good to know that you can set a default value in the mapping (regardless of whether you are mapping to an object or primitive) if that is what you need to do. You often don’t have control over a database/schema/data, and sometimes you don’t have control over a POJO either, so it is always nice to have the options and know how to use them.

Thanks for the tip, I don’t remember whether I knew this before or not because while I use iBatis as my preferred method of mapping POJOs to SQL and vice versa, I spend most of my time in the biz logic and not the persistence/query logic.

By: Mauli

Mauli — Mon, 30 Mar 2009 06:11:38 +0000

Why don’t you use Integer Objects instead of primitive types? That way your columns can have null without a problem. That is my definite aproach for enterprise apps, because there are always such problems. A different approach could be that you create setters which would set a default value in case of null.