[rules-dev] need advice re null handling

Michael Neale michael.neale at gmail.com
Sat Mar 17 19:24:35 EDT 2007 

well, with nulls, it only makes sense if you have knowledge that a given
field is NOT a primitive, which is clearly something that only the developer
would know.

So basically, from what I am hearing, because we transparently allow
primitives, null should not be treated specially, other then for equality.
Dealing with specific inequality for example:

Foo(field != 3) could be true if field is null. However, Foo(field <,
contains, > etcc....) will ALWAYS be false if field is null. The only thing
that could be true when a field is null is equality, or not equals.
I will add some more tests for this.

On 3/17/07, Felipe Piccolini <felipe.piccolini at bluesoft.cl> wrote:
>
> 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 guywho 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 expresionmade 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<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<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.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> > ------------------------------
> > _______________________________________________
> > rules-dev mailing list
> >
> > rules-dev at lists.jboss.orghttps://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
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070318/5b3ae693/attachment.html

More information about the rules-dev mailing list