if clause defaults to true

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

if clause defaults to true

Guy Rouillier
I have an update statement with a <set> clause.  In one of the nested
<if> statements, I had accidentally mistyped my condition:

<if test="iOption_id != 0">option_id = #{iOptionId, javaType=int,
jdbcType=VARCHAR},</if>

should have been

<if test="iOptionId != 0">option_id = #{iOptionId, javaType=int,
jdbcType=VARCHAR},</if>

My mapper interface looks like the following for that parameter:

@Param("iOptionId") int iOptionId,

After running the code, I looked in my database, and because of
historical records kept there, I could tell that my row went from
containing a non-zero value to containing a zero value.  So, that tells
me the original <if> statement evaluated to true and was included.

So, MyBatis wasn't finding the test parameter (because I mistyped it),
and yet the test evaluated to true.  If you can't find a data value,
then you can't say whether the if condition is true or false (the null
value problem.)  I would think defaulting to false would make more sense.

--
Guy Rouillier
Reply | Threaded
Open this post in threaded view
|

Re: if clause defaults to true

Clinton Begin
Administrator
Darn, this is entirely OGNL parsing... we just pass it into OGNL and whatever it evaluates to is taken as gospel.

Perhaps have a look through the OGNL user guide (we have a copy on the Google Code downloads) to see what this expression is actually evaluating to and why.

It's possible that it's as simple as "iOption_Id == null", and "null != 0", and thus "true".

Clinton

On Thu, Jan 6, 2011 at 11:03 PM, Guy Rouillier <[hidden email]> wrote:
I have an update statement with a <set> clause.  In one of the nested <if> statements, I had accidentally mistyped my condition:

<if test="iOption_id != 0">option_id = #{iOptionId, javaType=int, jdbcType=VARCHAR},</if>

should have been

<if test="iOptionId != 0">option_id = #{iOptionId, javaType=int, jdbcType=VARCHAR},</if>

My mapper interface looks like the following for that parameter:

@Param("iOptionId") int iOptionId,

After running the code, I looked in my database, and because of historical records kept there, I could tell that my row went from containing a non-zero value to containing a zero value.  So, that tells me the original <if> statement evaluated to true and was included.

So, MyBatis wasn't finding the test parameter (because I mistyped it), and yet the test evaluated to true.  If you can't find a data value, then you can't say whether the if condition is true or false (the null value problem.)  I would think defaulting to false would make more sense.

--
Guy Rouillier

Reply | Threaded
Open this post in threaded view
|

Re: if clause defaults to true

Herman Bovens
See the OGNL language guide, chapter 5: Chapter 5. Coercing Objects to Types.

Option_Id will be treated as a boolean "false" because it is null.  So !Option_Id will be "true", which is interpreted as 1 when comparing with an integer.  So "iOption_id != 0" results in "1 != 0 ", thus true.

Herman

2011/1/13 Clinton Begin <[hidden email]>
Darn, this is entirely OGNL parsing... we just pass it into OGNL and whatever it evaluates to is taken as gospel.

Perhaps have a look through the OGNL user guide (we have a copy on the Google Code downloads) to see what this expression is actually evaluating to and why.

It's possible that it's as simple as "iOption_Id == null", and "null != 0", and thus "true".

Clinton


On Thu, Jan 6, 2011 at 11:03 PM, Guy Rouillier <[hidden email]> wrote:
I have an update statement with a <set> clause.  In one of the nested <if> statements, I had accidentally mistyped my condition:

<if test="iOption_id != 0">option_id = #{iOptionId, javaType=int, jdbcType=VARCHAR},</if>

should have been

<if test="iOptionId != 0">option_id = #{iOptionId, javaType=int, jdbcType=VARCHAR},</if>

My mapper interface looks like the following for that parameter:

@Param("iOptionId") int iOptionId,

After running the code, I looked in my database, and because of historical records kept there, I could tell that my row went from containing a non-zero value to containing a zero value.  So, that tells me the original <if> statement evaluated to true and was included.

So, MyBatis wasn't finding the test parameter (because I mistyped it), and yet the test evaluated to true.  If you can't find a data value, then you can't say whether the if condition is true or false (the null value problem.)  I would think defaulting to false would make more sense.

--
Guy Rouillier


Reply | Threaded
Open this post in threaded view
|

Re: if clause defaults to true

Guy Rouillier
Ok, the OGNL Language Reference
(http://www.opensymphony.com/ognl/html/LanguageGuide/apa.html) is very
unambiguous:

"Equality is tested for as follows. If either value is null, they are
equal if and only if both are null."

There is more, but that's all that's necessary to resolve my <if>
condition.  Not at all what I would have expected with a numeric value
on the right; I would have expected the expression evaluator to attempt
to convert the left hand expression to something compatible with the
right hand expression.

But I didn't write the rules, and there you go.

On 1/13/2011 11:31 AM, Herman Bovens wrote:

> See the OGNL language guide, chapter 5: Chapter 5. Coercing Objects to
> Types.
>
> Option_Id will be treated as a boolean "false" because it is null.  So
> !Option_Id will be "true", which is interpreted as 1 when comparing with
> an integer.  So "iOption_id != 0" results in "1 != 0 ", thus true.
>
> Herman
>
> 2011/1/13 Clinton Begin <[hidden email]
> <mailto:[hidden email]>>
>
>     Darn, this is entirely OGNL parsing... we just pass it into OGNL and
>     whatever it evaluates to is taken as gospel.
>
>     Perhaps have a look through the OGNL user guide (we have a copy on
>     the Google Code downloads) to see what this expression is actually
>     evaluating to and why.
>
>     It's possible that it's as simple as "iOption_Id == null", and "null
>     != 0", and thus "true".
>
>     Clinton
>
>
>     On Thu, Jan 6, 2011 at 11:03 PM, Guy Rouillier <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         I have an update statement with a <set> clause.  In one of the
>         nested <if> statements, I had accidentally mistyped my condition:
>
>         <if test="iOption_id != 0">option_id = #{iOptionId,
>         javaType=int, jdbcType=VARCHAR},</if>
>
>         should have been
>
>         <if test="iOptionId != 0">option_id = #{iOptionId, javaType=int,
>         jdbcType=VARCHAR},</if>
>
>         My mapper interface looks like the following for that parameter:
>
>         @Param("iOptionId") int iOptionId,
>
>         After running the code, I looked in my database, and because of
>         historical records kept there, I could tell that my row went
>         from containing a non-zero value to containing a zero value.
>           So, that tells me the original <if> statement evaluated to
>         true and was included.
>
>         So, MyBatis wasn't finding the test parameter (because I
>         mistyped it), and yet the test evaluated to true.  If you can't
>         find a data value, then you can't say whether the if condition
>         is true or false (the null value problem.)  I would think
>         defaulting to false would make more sense.
>
>         --
>         Guy Rouillier
>
>
>


--
Guy Rouillier
Reply | Threaded
Open this post in threaded view
|

Re: if clause defaults to true

Herman Bovens
I think the equality test that you refer to happens after coercion: http://www.opensymphony.com/ognl/html/LanguageGuide/coercion.html


2011/1/14 Guy Rouillier <[hidden email]>
Ok, the OGNL Language Reference (http://www.opensymphony.com/ognl/html/LanguageGuide/apa.html) is very unambiguous:

"Equality is tested for as follows. If either value is null, they are equal if and only if both are null."

There is more, but that's all that's necessary to resolve my <if> condition.  Not at all what I would have expected with a numeric value on the right; I would have expected the expression evaluator to attempt to convert the left hand expression to something compatible with the right hand expression.

But I didn't write the rules, and there you go.


On 1/13/2011 11:31 AM, Herman Bovens wrote:
See the OGNL language guide, chapter 5: Chapter 5. Coercing Objects to
Types.

Option_Id will be treated as a boolean "false" because it is null.  So
!Option_Id will be "true", which is interpreted as 1 when comparing with
an integer.  So "iOption_id != 0" results in "1 != 0 ", thus true.

Herman

2011/1/13 Clinton Begin <[hidden email]
<mailto:[hidden email]>>


   Darn, this is entirely OGNL parsing... we just pass it into OGNL and
   whatever it evaluates to is taken as gospel.

   Perhaps have a look through the OGNL user guide (we have a copy on
   the Google Code downloads) to see what this expression is actually
   evaluating to and why.

   It's possible that it's as simple as "iOption_Id == null", and "null
   != 0", and thus "true".

   Clinton


   On Thu, Jan 6, 2011 at 11:03 PM, Guy Rouillier <[hidden email]
   <mailto:[hidden email]>> wrote:

       I have an update statement with a <set> clause.  In one of the
       nested <if> statements, I had accidentally mistyped my condition:

       <if test="iOption_id != 0">option_id = #{iOptionId,
       javaType=int, jdbcType=VARCHAR},</if>

       should have been

       <if test="iOptionId != 0">option_id = #{iOptionId, javaType=int,
       jdbcType=VARCHAR},</if>

       My mapper interface looks like the following for that parameter:

       @Param("iOptionId") int iOptionId,

       After running the code, I looked in my database, and because of
       historical records kept there, I could tell that my row went
       from containing a non-zero value to containing a zero value.
         So, that tells me the original <if> statement evaluated to
       true and was included.

       So, MyBatis wasn't finding the test parameter (because I
       mistyped it), and yet the test evaluated to true.  If you can't
       find a data value, then you can't say whether the if condition
       is true or false (the null value problem.)  I would think
       defaulting to false would make more sense.

       --
       Guy Rouillier





--
Guy Rouillier