Re: [rules-dev] need advice re null handling
I think Im not agree with that... the question here is about how the
Rule languaje will treat an expresion
made by a businness agent to the rules... so when a rule has a
condition writen like this:
Fact( field > 3)
this is asking : Is there a fact of type Fact which has a field
and the value of that value is greater that 3..
So, if the Fact actually exists and for 'some reason' its field
"field" has a value which is not greater than 3
(the rule doesn't need to know why the value is not 3, or is 0, or
null or whatever) then the condition must
return (or been evaluated as) false. Its responsability for the DAO
or fill implementation of the fact to put the
right value on its fields, the values that MEAN something. If its
null it is possible that the value was never
setted or initialized, or maybe it means something else. If a
bussiness guy wants to ask for been null
Fact( field == null)
then that question is a meaningfull one, dont let programmers decide
what it means. If I wanna to ask for
being greater that 3, and it has no value, then the answer is NO, "it
is NO greather than 3".
well... this is just my humile opinion btw....
On 15-03-2007, at 13:03, Tom Gonzalez wrote:
We handle it as it can't be anything else but null cause null is
returned when an access fails or some error occurs. This keeps it
from falling into a valid evaluation and possibly a subtle bug
going uncaught.
Tom G
From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-
bounces(a)lists.jboss.org] On Behalf Of Mark Proctor
Sent: Thursday, March 15, 2007 12:42 PM
To: Rules Dev List
Subject: Re: [rules-dev] need advice re null handling
Its not about giving it up, its how we handle when those fields are
null, do we treat it like a primitive and assume its 0, or do we
say it can't be equal to anything else but null.
In the following example neither y or z is defined, thus y is null
and z is 0;
int x = 0;
Integer y;
in z;
x == y // is false;
x == z // is true
y == null // is true
Mark
Tom Gonzalez wrote:
> The flexibility provided by an Object is very valuable. We use
> Integer and String objects all over the place today in our facts
> with drools. I would hate to give it up.
>
> Tom G
>
> From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-
> bounces(a)lists.jboss.org] On Behalf Of Mark Proctor
> Sent: Thursday, March 15, 2007 6:29 AM
> To: Rules Dev List
> Subject: Re: [rules-dev] need advice re null handling
>
> if bar is an integer it will be 0, if its an Integer it will be
> null. The Q is do we make Integer work like the primitive, or do
> we make it work like an Object.
>
> Mark
> Michael Neale wrote:
>> http://jira.jboss.com/jira/browse/JBRULES-627
>>
>> OK, this much is clear:
>>
>> Foo(field == null) can be true if field is null.
>>
>> but, what about Foo(field > 3), and field is null? should that be
>> false? what about Foo(field != 3) - should that be true?
>>
>> in SQL, null will always result in a false condition, unless you
>> explicitly use null.
>>
>> Thoughts?
>>
>> Michael.
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
Attachments:
- attachment.html (text/html — 7.7 KB)