Re: [rules-users] qualified identifiers in constraints: not commutative?

Thanks again, but your read of the "small print" perhaps explains why the parens make (o.q > (o.b.maxQ)) work, but does not explain why (o.q > o.b.maxQ) does not work while (o.b.maxQ < o.q) does work. On 12/31/2010 3:18 PM, Wolfgang Laun wrote: > On 31 December 2010 19:05, Michael Whidden

Re: [rules-users] qualified identifiers in constraints: not commutative?

On 31 December 2010 19:05, Michael Whidden wrote: > Thank you! That fixes it, without using getter methods. So did I make a > mistake, or is this a workaround for a bug? > Very careful reading of the very, very small print in the Expert manual section describing the various forms of field constr

Re: [rules-users] qualified identifiers in constraints: not commutative?

Thank you! That fixes it, without using getter methods. So did I make a mistake, or is this a workaround for a bug? These work: $o:Order(q > (b.maxQ)) $o:Order($o.q > ($o.b.maxQ)) $o:Order(b.maxQ > q) $o:Order($o.b.maxQ > $o.q) These don't: $o:Order(q > b.maxQ) $o:Order($o.q > $o.b.maxQ) Is thi

Re: [rules-users] qualified identifiers in constraints: not commutative?

Try parenthesizing the right hand side but note that you may have to use getters to access the fields $o:Order($o.q > ($o.getB().getMaxQ() ) ) It's possible that using dialect "mvel" might be a way to avoid using the getX() instead of x. -W On 31 December 2010 17:30, Michael Whidden wrote:

Re: [rules-users] qualified identifiers in constraints: not commutative?

At Mr. Legendre's suggestion, I removed the $o from my constraints, but with the same result: (b.maxQ < q) works, but (q > b.maxQ) fails. I get the error: "Unable to create restriction '[QualifiedIndentifierRestr: < b.maxQ ]' for field 'quantity' in the rule 'MaxQty'" On 12/30/2010 2:32 PM, Mi

Re: [rules-users] Facts with "from"

Thanks for the confirmation :-) Happy new year. Chris On 31/12/2010 15:14, Wolfgang Laun wrote: Hmm, you asked whether "do I take it that...", which I take to mean the same as "should I assume that...". Hence: yes, you should! Indirect figures of speech are always suprising if replied to at

Re: [rules-users] Facts with "from"

Hmm, you asked whether "do I take it that...", which I take to mean the same as "should I assume that...". Hence: yes, you should! Indirect figures of speech are always suprising if replied to at face value. Q. "May I ask you how olod you are?" A. "Yes, you may." WME = Working Memory Elements.

Re: [rules-users] Facts with "from"

I assume that you mean that Yes they don't rather than Yes they do :-) (Isn't english so imprecise?) (WMEs? Working Memory Entries?) Chris On 31/12/2010 12:55, Wolfgang Laun wrote: On 31 December 2010 11:33, Chris Selwyn > wrote: I am trying to unde

Re: [rules-users] Facts with "from"

On 31 December 2010 11:33, Chris Selwyn wrote: > I am trying to understand the usage of "from". > > Do I take it that facts that come from a "from" CE do not actually get > asserted into the WM? > Yes. (They might happen to be WMEs, if you have inserted them.) -W > > I would like to be sure be

Re: [rules-users] Subject: Drools Planner - Design Suggestions

Just to complete my first ideas: Once you have your time partition in slots, and ads assigned in them in an obvious way, you can use drools-planner to optimize on more complex criteria / contraints with a simple swap move. You can then handle preference in times for

Re: [rules-users] Subject: Drools Planner - Design Suggestions

Title: CARTE DE VISITE Hi, If I understand well :    - you have only one ad at a time, displayed at least 10 minutes and at most 60 minutes, and I suppose that ads cannot be fractionned.    - ads can be ordered by their "value" for one click The main ob

Re: [rules-users] qualified identifiers in constraints: not commutative?

Title: CARTE DE VISITE Try without your $o in your constraints. EG try with :     $o:Order(b.maxQ < q)     $o:Order(q > b.maxQ) I suppose that as $o is the object itself, it may be binded only AFTER your pattern (in parser), and could leads to some

[rules-users] Facts with "from"

I am trying to understand the usage of "from". Do I take it that facts that come from a "from" CE do not actually get asserted into the WM? I would like to be sure because the facts that I would like to fetch with "from" are actually the same Java class as one of my WM facts but I do not want