[rules-dev] need advice re null handling

Fri Mar 16 11:26:50 EDT 2007

As I see it, this is not like SQL, because Tom said "null is returned  
when an access fails or some error occurs", but then the guy
who prepare the SQL statements has to be acknowloedge of the meaning  
of a null return, so he writes the querys in a
correct way to the application. Here thats not the case, the guy who  
writes the rules doesn't need to know why that
field is null, or 0 or blank, he ask for a statement of truth (field ! 
= 3), he spect not reason why that field is not 3, maybe
the value of the field is 0,1,2,4,5... null, " ", or whatever another  
value possible, he is just asking to not be specific one.
If someone need to manage the null value in a diferent way, then he  
must prepare the Fact Objects, Value Objects, Pojos,
Wrappers in a diferent way, design to do what he wants to be done  
with null values but not at the rules language level.

If I wanna ask for null value in a field to check for errors for  
example, I should ask for that " Fact( field == null )".

Maybe it could be a parametric flag somewhere telling the engine how  
to manage nulls, and set a default...

Another question: How the engine manage to return to Fact( field ==  
null) when field is a primitive?, it makes autoboxing?,
comaparing Integer (for int) to null or something like that?, if the  
Engine do so, why?, maybe the rule's writer was wrong when
he wrote that, or maybe he just wanted to check if the field is blank/ 
zero/not setter/etc...

On 15-03-2007, at 20:23, Michael Neale wrote:

> Felipe - yes that is consistent.
>
> But what about:
>
> Fact( field != 3 )
> now if field is null, its certainly not equal to 3, but should this  
> be true? or because of null, it is always false?
>
> In SQL, it would always be false.
>
> On 3/16/07, Felipe Piccolini <felipe.piccolini at bluesoft.cl> wrote:
> 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 at lists.jboss.org [ mailto:rules-dev- 
>> bounces at 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 at lists.jboss.org [ mailto:rules-dev- 
>>> bounces at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>>
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> Felipe Piccolini M.
> felipe.piccolini at bluesoft.cl
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

Felipe Piccolini M.
felipe.piccolini at bluesoft.cl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070316/53fe3cde/attachment.html 