Re: Why does myBatis not set value to POJO when query return null of a field?

[Eduardo Macarron]

MyBatis does not call the POJO's setter when the value is null.

The main problem is, how should we deal with primitives?

If a field is an int it will not accept a null but we cannot assume
that null means 0.

We could bypass setting null if the property is a primitive but...
that hurts consistence and brings complexity.

So... unless I find a consistent way to handle nulls I would say it is
better to bypass them as MB does now.

thoughts?

[Dridi Boukelmoune]

Hi,

How about a method containing the wasNull part, web could then override it and tune the behavior.

Dridi
http://www.zenika.com/

[Eduardo Macarron]

Sorry, I meant unless "we" find, not me :) I do not know how to solve it.

BTW, hibernate fails when mapping a null to a primitive. That is
indeed a consistent solution but I am fairly sure that bypassing nulls
will create less issues.

One possible solution is letting the user choose if he wants nulls to
be set or not with a new global configuration property like
"callSettersOnNulls". In that case it will call always to the setter
wether it is a primitive or not.

2012/6/18 Eduardo Macarron <eduardo....@gmail.com>:

[Eduardo Macarron]

You mean in the TypeHandler?

[Dridi Boukelmoune]

Yes in thé abstract built-in typehandler .

[Eduardo Macarron]

Not sure it is needed. You can already replace null by another value
using current getResult method from TypeHandler interface or overiding
it from BaseTypeHandler.

In fact, that is what Chan Wai Lun should do to fix the issue with current code.

2012/6/18 Dridi Boukelmoune <dridi.bo...@zenika.com>:

[Ravi Thapa]

Even i faced the same issue, when a null value is returned then i do get the exception. So my question is how to handle null value the in Ibatis.

Please can you show any example it would be grateful for me, as i am still learning Ibatis.

--
Thanks and Regards

[Eduardo Macarron]

Hi Ravi, could you post the stacktrace?

[Chan Wai Lun]

Hi Edurado,

Thank you very much, now I can understand the reason of doing so.

Yes I agree that is what I should do it... but why I asked this question was because in my mind, when I read the documentation and examples, extending baseTypeHandler and implement the getNullableResult should let me have the control on how the result should be return to myBatis... just like, if in some case I have to write some code to turn the result from query to something other before it send to myBatis for further process... I did not expect myBatis will check the original value that the query returned instead of checking the value returned by the custom type handler... maybe i missed it somewhere in the documentation... haha.

Thanks and Regards,

Wai Lun

Eduardo於 2012年6月18日星期一UTC+8下午10時46分55秒寫道：

[Ravi Thapa]

Can anyone tell how to use ibatis framework in java with relation to creating a connection pool in jboss server. I am not getting any suitable example. If anyone can tell me how to configure and how i can use it java.  

Waiting for your repsonse..

--
Thanks and Regards

[Eduardo Macarron]

Ravi, the setting up of the pool in JBoss is the same than for JDBC code.

In MyBatis set the transaction factory to JNDI

http://www.mybatis.org/core/configuration.html

2012/6/21 Ravi Thapa <ravit...@gmail.com>:

[Stephen Friedrich]

I think this behavior is a Bad Thing: It violates the principle of least surprise.

When I read an object the natural assumption is that it holds exactly the values returned from the mapped statement.
When the object has primitive fields, but null is returned from the db, then a natural way to handle it would be to throw an exception. It's clearly a programmer error to use a primitive field for a nullable column.

This probably cannot be changed in a minor version, but a configuration option would be very welcome!
IMHO for the next major version this natural behavior should be the default.

For motivation here's a real scenario that just happened to me.
I had a lot of "fun" debugging this very strange and surprising error:
We got a complaint that a user was not able to log-in. He had just changed his password, but was pretty sure that the entered password was correct.
When debugging this I noticed that my "user" DTO read with mybatis _always_ contained a salt value for the password hash, even if it was null in the db. (Happens for users that were created before we added password salting).
I asked a colleague to come over and help me debug this under the assumption that there is a dumb error in the code that I just don't notice, because I am too familiar with the code.
But we both were stumped when we looked at the object returned from mybatis versus the same query executed directly on the database.
We checked if we were looking at the same db for both versions, that all transactions were commited and just looked clueless at the code.
The solution to the riddle was that somebody noticed code duplication and refactored it: Everywhere a "user" dto was created a random salt was set afterwards. So a better, more DRY way seemed to move the salt initialization to the field of the user dto. :-(

[Eduardo Macarron]

Hi Stephen. Your post makes a lot sense. I will try to add that config param for 3.2. Thanks for sharing your point of view.

2012/8/16 Stephen Friedrich <stephen....@fortis-it.de>

[Guy Rouillier]

On 8/16/2012 11:19 AM, Stephen Friedrich wrote:
> When I read an object the natural assumption is that it holds exactly
> the values returned from the mapped statement.
> When the object has primitive fields, but null is returned from the db,
> then a natural way to handle it would be to throw an exception. It's
> clearly a programmer error to use a primitive field for a nullable column.

I don't agree with the last statement. One of the strong points of
MyBatis (the reason we adopted it) was it functions well in the presence
of "impedance" mismatch. We have many legacy databases that are not
well normalized and missing a lot of referential integrity checks.
MyBatis continues to provide a useful mapping in this environment, while
a more strict solution like Hibernate would simply not work.

Having said all that, you obviously can't stuff a null into an int. So,
the problem is not using a primitive field for a nullable column, but
failing to account for it in the SQL.

--
Guy Rouillier