Null Handling in CAY-1860

[David Feshbach <dj...@gmail.com>]

I came across a breaking change in the way expressions are evaluated in memory when trying out trunk. A null value on the left hand side of a comparison (ASTGreater in my case) used to cause evaluateNode to return false. Now it throws an UnsupportedOperationException. A null value on the right hand side of a comparison used to return false, now it throws a NullPointerException. I'm not sure how I would get around this without littering all my expressions with isNotNulls. Maybe Expression.match could catch the exceptions and return false?

Re: Null Handling in CAY-1860

[David Feshbach <dj...@gmail.com>]

Hi Andrus,

Thanks for working so quickly to address my issue. I'm still having trouble comparing object paths in cases where the left hand side is not null and the right hand side is null. For example:

Artist a1 = new Artist();
a1.setArtistName("Name");
Expression expression = Expression.fromString("artistName > someOtherProperty");
assertFalse(expression.match(a1));

Other than that, the new behavior matches pre-CAY-1860 behavior and I don't have any other issues with current projects.

There are still differences in behavior between in-memory matching and matching in SQL for composite expressions involving nulls, e.g. NOT (NULL > 0). If this is planned, I'm happy to contribute.

For completeness, it would be nice to make a distinction between "= NULL" and "IS NULL", though I'm having to stretch to find a case where someone would want a literal equals. Maybe Artist.DATE_OF_BIRTH.eq(a1.getDateOfBirth()) shouldn't match any rows if a1 doesn't have a date of birth?

Thanks again,

David

On Feb 22, 2014, at 4:46 AM, Dzmitry Kazimirchyk <dk...@gmail.com> wrote:

> I think I've reported something similar already: https://issues.apache.org/jira/browse/CAY-1877
> 
> Perhaps this can be updated with additional details.
> 
> Dima
> 
> On 02/22/2014 12:50 PM, Andrus Adamchik wrote:
>> Sounds like a bug. Could you open a Jira please?
>> 
>> Thanks,
>> Andrus
>> 
>> On Feb 22, 2014, at 1:33 AM, David Feshbach <dj...@gmail.com> wrote:
>> 
>>> I came across a breaking change in the way expressions are evaluated in memory when trying out trunk. A null value on the left hand side of a comparison (ASTGreater in my case) used to cause evaluateNode to return false. Now it throws an UnsupportedOperationException. A null value on the right hand side of a comparison used to return false, now it throws a NullPointerException. I'm not sure how I would get around this without littering all my expressions with isNotNulls. Maybe Expression.match could catch the exceptions and return false?
> 

Re: Null Handling in CAY-1860

[Dzmitry Kazimirchyk <dk...@gmail.com>]

I think I've reported something similar already: 
https://issues.apache.org/jira/browse/CAY-1877

Perhaps this can be updated with additional details.

Dima

On 02/22/2014 12:50 PM, Andrus Adamchik wrote:
> Sounds like a bug. Could you open a Jira please?
>
> Thanks,
> Andrus
>
> On Feb 22, 2014, at 1:33 AM, David Feshbach <dj...@gmail.com> wrote:
>
>> I came across a breaking change in the way expressions are evaluated in memory when trying out trunk. A null value on the left hand side of a comparison (ASTGreater in my case) used to cause evaluateNode to return false. Now it throws an UnsupportedOperationException. A null value on the right hand side of a comparison used to return false, now it throws a NullPointerException. I'm not sure how I would get around this without littering all my expressions with isNotNulls. Maybe Expression.match could catch the exceptions and return false?

Re: Null Handling in CAY-1860

[Andrus Adamchik <an...@objectstyle.org>]

Sounds like a bug. Could you open a Jira please?

Thanks,
Andrus

On Feb 22, 2014, at 1:33 AM, David Feshbach <dj...@gmail.com> wrote:

> I came across a breaking change in the way expressions are evaluated in memory when trying out trunk. A null value on the left hand side of a comparison (ASTGreater in my case) used to cause evaluateNode to return false. Now it throws an UnsupportedOperationException. A null value on the right hand side of a comparison used to return false, now it throws a NullPointerException. I'm not sure how I would get around this without littering all my expressions with isNotNulls. Maybe Expression.match could catch the exceptions and return false?