laune wrote
> I'd suggest you just fix the parser so it doesn't accept this and
> diagnoses an error.
I'll make it so, Thanks.
--
View this message in context:
http://drools.46999.n3.nabble.com/how-is-Integer-converted-when-comparing-with-primitive-tp4019975p4020017.html
Sent from the Drools:
On 27/09/2012, Mario Fusco wrote:
I am just guessing now,
> but it seems to me that instead of testing lowerBound < value < upperBuond
> it is actually only checking lowerBound < upperBuond because the only way
> to avoid that the rule fires is to write a pattern like: Cont( 11 < val <
> 10
I ca
I checked the documentations and it didn't mention that constraint format. I
must have misread it as being valid and assumed it would work since there
was never any errors. I will correct it and use something like Fact(val <
10 && > 4) or break them out into two.
Thanks for the investigation.
Wolfgang,
thanks for having tried this, but following your examples I made some
further tests (on the master branch) end it seems to me that constraints in
the from lowerBound < value < upperBuond are not working at all regardless
of the fact if value is null or not.
For instance I tried
declare
Thanks for the detailed explanations. We added the a check for null so that
rule doesn't fire anymore.
--
View this message in context:
http://drools.46999.n3.nabble.com/how-is-Integer-converted-when-comparing-with-primitive-tp4019975p4020012.html
Sent from the Drools: User forum mailing l
DRL, followed by results from 5.2.0,5.3.0, 5.4.0
Cheers
Wolfgang
declare Cont
val:Integer
end
rule makeFacts
salience 99
when
then
insert( new Cont() );
end
rule "val <= Integer.MAX_VALUE"
when
$c: Cont( val <= Integer.MAX_VALUE )
then
System.out.println( drools.getRule().getNa
On 27/09/2012, Mario Fusco wrote:
> Hi,
>
> this is definitively a bug and I will start working asap to fix it. By the
> way which version of Drools are you using?
I'll report this in detail ASAP, using a simple example.
>
> I think that in your case null has exactly the same semantic of NaN. It
Hi,
this is definitively a bug and I will start working asap to fix it. By the
way which version of Drools are you using?
I think that in your case null has exactly the same semantic of NaN. It
means that any comparison against it ( even currentLateCount <=
Integer.MAX_VALUE ) shouldn't match.
At the time of a release I get a ton of reports in my mailbox due to
my previous JIRAs being pushed into the future. My eagerness to add to
this list is asymptotically approaching guess what.
-W
On 27/09/2012, Davide Sottara wrote:
> Has it been reported in a JIRA ticket? That's the best way to
Has it been reported in a JIRA ticket? That's the best way to get it reported
and fixed
Thanks
Davide
--
View this message in context:
http://drools.46999.n3.nabble.com/how-is-Integer-converted-when-comparing-with-primitive-tp4019975p4019985.html
Sent from the Drools: User forum mailing list ar
This is a bug, manifest in all versions since 5.2.0. Actually it is a
"multibug", exhibiting a series of surprising inconsistencies.
* That null is silently ignored isn't documented (not for operators
'<' and '>').
* One might expect 0 to be used as the only reasonable default, but it isn't.
Hello
I have a rule that looks something like this
when
$mydate : TaskRowDate(0 < currentLateCount < 100)
then
doSomething();
My problem is that currentLateCount is an Integer type because i want to be
able to store null. 0 means something different in my app.
The problem is when a f
12 matches
Mail list logo
