[rules-users] Dynamic JavaBeans
Felipe Piccolini
felipe.piccolini at bluesoft.cl
Fri Jun 29 18:41:57 EDT 2007
Wel... making more tests... I think i was wrong about dynamic
JavaBeans... I dont think the problem is there...
using update($fact) after modify makes the same issue...
Consider this:
//-------FACT-----------------------------
public class Fact implements Serializable {
private static final long serialVersionUID = 331627137981862975L;
private int number;
public Fact(int number){
this.number = number;
}
public Fact(){
this(0);
}
/**
* @return the number
*/
public int getNumber() {
return number;
}
/**
* @param number the number to set
*/
public void setNumber(int number) {
this.number = number;
}
}
//-------RULES-----------------------------
package cl.bluesoft.test
#list any import classes here.
import java.util.List
import java.util.ArrayList
import cl.bluesoft.test.rules.Fact
#declare any global variables here
rule "test update A"
salience 699
no-loop
when
$f : Fact($n: number > 0)
$list: ArrayList( this excludes "key1")
then
System.out.println("A-fact number1:"+$f.getNumber()+" list 1:"+$list);
$list.add("key1");
$f.setNumber($n + 1);
update ($f);
update ($list);
System.out.println("A-fact number2:"+$f.getNumber()+" list 2:"+$list);
end
rule "test update B"
salience 699
no-loop
when
$f : Fact($n: number > 1)
$list: ArrayList( this excludes "key2")
then
System.out.println("B-fact number1:"+$f.getNumber()+" list 1:"+$list);
$list.add("key2");
$f.setNumber($n + 1);
update ($f);
update ($list);
System.out.println("B-fact number2:"+$f.getNumber()+" list 2:"+$list);
end
//------TEST---------
public class TestUpdateFact implements Serializable {
private static final long serialVersionUID = -574789596641083743L;
/**
* @param args
*/
public static void main(String[] args) {
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
Package pkg = builder.getPackage();
....
WorkingMemory session = ruleBase.getStatefulSession();
...etc etc...
List list = new ArrayList();
Fact fact1 = new Fact(1);
session.fireAllRules();
....etc, etc...
}
}
//--------OUTPUT------------
A-fact number1:1 list 1:[]
A-fact number2:2 list 2:[key1]
B-fact number1:2 list 1:[key1]
B-fact number2:3 list 2:[key1, key2]
A-fact number1:3 list 1:[key1, key2]
A-fact number2:4 list 2:[key1, key2, key1]
B-fact number1:4 list 1:[key1, key2, key1]
B-fact number2:5 list 2:[key1, key2, key1, key2]
A-fact number1:5 list 1:[key1, key2, key1, key2]
A-fact number2:6 list 2:[key1, key2, key1, key2, key1]
B-fact number1:6 list 1:[key1, key2, key1, key2, key1]
B-fact number2:7 list 2:[key1, key2, key1, key2, key1, key2]
A-fact number1:7 list 1:[key1, key2, key1, key2, key1, key2]
A-fact number2:8 list 2:[key1, key2, key1, key2, key1, key2, key1]
B-fact number1:8 list 1:[key1, key2, key1, key2, key1, key2, key1]
.... for ever.....
So I have a loop... only when I use update and both rules...
condition about the
list not containing "key1" and "key2" seems not properly chequed... I
dont know...
Can somebody help me? I am missiong something here?
Thanks.
On 29-06-2007, at 17:33, Felipe Piccolini wrote:
>
> Mark,
>
> I'v been trying to get the way to patch that, but I must confess
> that is way too complex for me now.. My best
> guess is that when the update(retract/insert) is done, it just take
> the factHandle modified to rebuild the ReteRuleBase
> so when the activations are setted in place this doesnt care about
> another fact update to fill the AgendaGroupImpl.
>
> I dont really know the best way to modify the code... I bow
> before u guys...
>
> Also tried your suggestion using something like : modify
> ( cheese ) { price = 25, quality = premium }
>
> But I get compilation erros saying that "modify(myFact) is not
> defined"... so I dont really know how to use
> this MVEL functionality... got ur "what is new in drools 4.0",
> search at examples and mailing-list, but cant get the right way
> to make that work.
>
> If you could help me with any working example, or maybe a work-
> around... I sont wanna use a set of rules that must be writen in a
> sequence mode using salience.... I need to write a lot of rules in
> an independent way.
>
> Sorry for my english, and thank you very much.
>
>
> On 28-06-2007, at 16:43, Mark Proctor wrote:
>
>> feel free to work on a patch for us and let us know what you come
>> up with.
>>
>> Mark
>> Felipe Piccolini wrote:
>>> Mark,
>>>
>>> What about my previous mail where I report an issue with
>>> update using dynamic JavaBeans (using propertyListeners)?
>>>
>>> The problem is that when the engine is fired again from an
>>> propertyListener the evaluations on conditions (seems to me)
>>> dont take the new state of the Facts changed in the
>>> set<Attribute> call.
>>>
>>> I will try using MVEL modify, but thats not the better solution,
>>> because the feature of propertyListerners inside javaBeans let
>>> me write my rules in a cleaner way from BRMS/bussines editor.
>>>
>>> Thanks.
>>>
>>>
>>> On 28-06-2007, at 8:28, Mark Proctor wrote:
>>>
>>>> If it can be done cleanly I'm not averse to it. however there is
>>>> something else...
>>>> In the new MVEL dialect you no longer need
>>>> propertychangelisteners if you don't want to call update()
>>>>
>>>> modify ( cheese ) { price = 25, quality = premium }
>>>>
>>>> This will modify all the setters and notify the engine at the
>>>> end of the block setter. Is that good enough for you?
>>>>
>>>> Mark
>>>> Yuri de Wit wrote:
>>>>> Mark,
>>>>>
>>>>> btw, If this is a feature that makes sense from Drools pov I
>>>>> wouldnt
>>>>> mind giving a shot at implementing it and contributing it back to
>>>>> Drools.
>>>>>
>>>>> -- yuri
>>>>>
>>>>> On 6/28/07, Yuri de Wit <ydewit at gmail.com> wrote:
>>>>>> Sure. The solution I am taking right now is dont use dynamic
>>>>>> properties, which is not optimal (depending on the problem
>>>>>> property
>>>>>> changes not being batched defeats the purpose of dynamic beans).
>>>>>>
>>>>>> The bottom line is that I was hoping that this feature would (1)
>>>>>> either already be taken care of in 4.0 or (2) become a feature
>>>>>> request
>>>>>> for future releases.
>>>>>>
>>>>>> -- yuri
>>>>>>
>>>>>> On 6/28/07, Mark Proctor <mproctor at codehaus.org> wrote:
>>>>>> > No we don't do anything to batch property change listener
>>>>>> results. But
>>>>>> > maybe you can do this yourself.
>>>>>> > instead of calling modify, add it to a transaction list
>>>>>> (that you make
>>>>>> > available in the current context). Then at the end of the
>>>>>> consequence
>>>>>> > you can iterate that list and call modify on each object. Or
>>>>>> > alternatively don't use dynamic properties.
>>>>>> >
>>>>>> > Mark
>>>>>> > Yuri de Wit wrote:
>>>>>> > > I am not talking about assert, but modify. I have a
>>>>>> dynamic fact
>>>>>> > > already asserted but now I need to perform N changes on N
>>>>>> different
>>>>>> > > properties on the same object on the same consequence.
>>>>>> Drools is going
>>>>>> > > to traverse the RETE network N times once for each time the
>>>>>> > > PropertiesListener is called (each setProperty called).
>>>>>> > >
>>>>>> > > -- yuri
>>>>>> > >
>>>>>> > > On 6/28/07, Mark Proctor <mproctor at codehaus.org> wrote:
>>>>>> > >> Why would doing the assert work at the end of the
>>>>>> consequence be any
>>>>>> > >> quicker than doing it during the consequence?
>>>>>> > >>
>>>>>> > >> Mark
>>>>>> > >> Yuri de Wit wrote:
>>>>>> > >> > I noticed that changes performed on facts asserted
>>>>>> dynamically causes
>>>>>> > >> > the fact to be modified right away and therefore
>>>>>> triggering a RETE
>>>>>> > >> > network traversal and rule schedulings.
>>>>>> > >> >
>>>>>> > >> > For apps with a large number of facts this could be a
>>>>>> significant
>>>>>> > >> > scalability problem. At least in my case, I would like
>>>>>> to be able to
>>>>>> > >> > use dynamic facts and perform any number of updates and
>>>>>> have those
>>>>>> > >> > updates commited to working memory only when the rule
>>>>>> consequence is
>>>>>> > >> > completed.
>>>>>> > >> >
>>>>>> > >> > Looking at the code, it seems that it would not be a
>>>>>> major effort to
>>>>>> > >> > collect the facts received by the
>>>>>> ReteooWorkingMemory.propertyChange
>>>>>> > >> > and perform the actual modifyObject() only when the
>>>>>> consequence
>>>>>> > >> > evaluation is actually completed.
>>>>>> > >> >
>>>>>> > >> > Does that makes sense? Or are there side effects I am
>>>>>> not seeing? Is
>>>>>> > >> > this a problem that 4.0 already resolves?
>>>>>> > >> >
>>>>>> > >> > thanks in advance,
>>>>>> > >> >
>>>>>> > >> > -- yuri
>>>>>> > >> > _______________________________________________
>>>>>> > >> > rules-users mailing list
>>>>>> > >> > rules-users at lists.jboss.org
>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>> > >> >
>>>>>> > >>
>>>>>> > >> _______________________________________________
>>>>>> > >> rules-users mailing list
>>>>>> > >> rules-users at lists.jboss.org
>>>>>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>> > >>
>>>>>> > > _______________________________________________
>>>>>> > > rules-users mailing list
>>>>>> > > rules-users at lists.jboss.org
>>>>>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>> > >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > rules-users mailing list
>>>>>> > rules-users at lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>> >
>>>>>>
>>>>> _______________________________________________
>>>>> rules-users mailing list
>>>>> rules-users at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>> Felipe Piccolini M.
>>> felipe.piccolini at bluesoft.cl
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> Felipe Piccolini M.
> felipe.piccolini at bluesoft.cl
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
Felipe Piccolini M.
felipe.piccolini at bluesoft.cl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070629/be01a58d/attachment.html
More information about the rules-users
mailing list