[rules-dev] need advice re null handling

Tue Mar 20 15:17:12 EDT 2007

Sounds right.

Thanks,

Tom G

________________________________

From: rules-dev-bounces at lists.jboss.org
[mailto:rules-dev-bounces at lists.jboss.org] On Behalf Of Michael Neale
Sent: Saturday, March 17, 2007 7:25 PM
To: Rules Dev List
Subject: Re: [rules-dev] need advice re null handling

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 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 <mailto: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
<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
<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
<mailto:rules-dev at lists.jboss.org> 

https://lists.jboss.org/mailman/listinfo/rules-dev

________________________________

_______________________________________________
				rules-dev mailing list

				rules-dev at lists.jboss.org
<mailto: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
<mailto: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
<mailto: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/20070320/c367e0ba/attachment.html 