[rules-users] Dynamic JavaBeans
Felipe Piccolini
felipe.piccolini at bluesoft.cl
Fri Jun 29 17:33:04 EDT 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070629/f799a09c/attachment.html
More information about the rules-users
mailing list