I'm seeing a strange behaviour when using complex
properties (select statements in resultMaps).
When the column used for the nested select statement
(PRD_CAT_ID on page 25 for example) is NULL, the
statement will be executed with an invalid value (ie:
getCategory would be called with #value# = 0).
I understand that this is not a simple issue, but shouldn't
there be a way to specify how to treat NULL values in
these situations?
I my case, I don't want the statement to be called at
all: my PRD_CAT_ID column is a FK, which specifically
means that nothing exists in CATEGORY for this specific
row... This situation is probably what people are dealing
with most of the time: column A in Table 1 is a FK on
column B in Table 2; column A is nullable because not all
Table 1 records have a relation to a record in Table 2.
From the example on page 25 that would mean that not
all products have a category.
What's your take on this one Clinton?
Thanks,
Phil
--------------------
By: Clinton Begin - cbegin
RE: Null values and Complex Properties
2004-04-28 20:33
If the key is null, then I suppose we should just catch
that and NOT run the second select. Of course, you
would have to use an Integer instead of an int. This
would also cause a problem for statements that rightfully
support something like IS NUll. However, that's pretty
rare and a bridge we can cross when we come to it. The
latter is probably < 20% of cases so we can make the
workaround for that situation.
1) This behaviour is correct, but I can see the need for
what you're asking for.
2) Your current situation seems like one that could be
solved by using a nullable type, like Integer vs. int, so
that #value# = null instead of #value# = 0 (as you indicated
above).
3) There are backward compatibility considerations with this
on. But I think there are a couple different ways to handle
this in the future. We could add an attribute to the
<result> element like runIfNull="false", or we could add a
dynamic element like <stop/> that would stop the execution
of the statement and just return null or an empty collection.
If everyone agrees, then I'll move this to feature requests.
Thoughts?
Clinton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Yes, the behaviour is correct as long as the value in the second select statement is null (not 0).
2) Exactly. Currently, I am using a nullable type (java.lang.Integer) so I should be getting null as the value in the second statement. I'll have to double-check but I'm pretty sure I'm getting a 0.
3) I agree with your backward compatibility consideration. I think adding a parameter in the resultMap is the best way to go: runIfNull="false" to prevent execution and it would be "true" by default so nothing should break.
I'm not very fond of a <stop/> tag: it should be the job of the calling mechanism to make sure all the parameters are set/valid. In my logic, calling a statement means I'm expecting it to actually execute... If the statement is invalid, I should get an exception.
I'm currently not able to test whether I'm getting null or a 0 using an Integer type key. Could this be quickly tested by someone? I figure it would be a bug if we're seeing a 0 instead of null...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Moved from bugs.
-----------------
By: Nobody/Anonymous - nobody
Null values and Complex Properties
2004-04-28 07:13
Hello,
I'm seeing a strange behaviour when using complex
properties (select statements in resultMaps).
When the column used for the nested select statement
(PRD_CAT_ID on page 25 for example) is NULL, the
statement will be executed with an invalid value (ie:
getCategory would be called with #value# = 0).
I understand that this is not a simple issue, but shouldn't
there be a way to specify how to treat NULL values in
these situations?
I my case, I don't want the statement to be called at
all: my PRD_CAT_ID column is a FK, which specifically
means that nothing exists in CATEGORY for this specific
row... This situation is probably what people are dealing
with most of the time: column A in Table 1 is a FK on
column B in Table 2; column A is nullable because not all
Table 1 records have a relation to a record in Table 2.
From the example on page 25 that would mean that not
all products have a category.
What's your take on this one Clinton?
Thanks,
Phil
--------------------
By: Clinton Begin - cbegin
RE: Null values and Complex Properties
2004-04-28 20:33
If the key is null, then I suppose we should just catch
that and NOT run the second select. Of course, you
would have to use an Integer instead of an int. This
would also cause a problem for statements that rightfully
support something like IS NUll. However, that's pretty
rare and a bridge we can cross when we come to it. The
latter is probably < 20% of cases so we can make the
workaround for that situation.
I'll bug it.
Date: 2004-05-02 18:16
Sender: cbegin
Logged In: YES
user_id=165324
Phil,
Few things:
1) This behaviour is correct, but I can see the need for
what you're asking for.
2) Your current situation seems like one that could be
solved by using a nullable type, like Integer vs. int, so
that #value# = null instead of #value# = 0 (as you indicated
above).
3) There are backward compatibility considerations with this
on. But I think there are a couple different ways to handle
this in the future. We could add an attribute to the
<result> element like runIfNull="false", or we could add a
dynamic element like <stop/> that would stop the execution
of the statement and just return null or an empty collection.
If everyone agrees, then I'll move this to feature requests.
Thoughts?
Clinton
1) Yes, the behaviour is correct as long as the value in the second select statement is null (not 0).
2) Exactly. Currently, I am using a nullable type (java.lang.Integer) so I should be getting null as the value in the second statement. I'll have to double-check but I'm pretty sure I'm getting a 0.
3) I agree with your backward compatibility consideration. I think adding a parameter in the resultMap is the best way to go: runIfNull="false" to prevent execution and it would be "true" by default so nothing should break.
I'm not very fond of a <stop/> tag: it should be the job of the calling mechanism to make sure all the parameters are set/valid. In my logic, calling a statement means I'm expecting it to actually execute... If the statement is invalid, I should get an exception.
I'm currently not able to test whether I'm getting null or a 0 using an Integer type key. Could this be quickly tested by someone? I figure it would be a bug if we're seeing a 0 instead of null...