8:29 p.m.
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
9:20 p.m.
New subject: Fwd: Dynamic JavaBeans
Sorry if this gets second posted, but it seems that the first one
didnt go through...
---------- Forwarded message ----------
From: Yuri de Wit <ydewit(a)gmail.com>
Date: Jun 27, 2007 8:29 PM
Subject: Dynamic JavaBeans
To: Rules Users List <rules-users(a)lists.jboss.org>
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
3:20 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:03 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:23 a.m.
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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:35 a.m.
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(a)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(a)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(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:40 a.m.
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(a)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(a)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(a)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(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/rules-users
> >> >
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
8:28 a.m.
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(a)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(a)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(a)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(a)lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
> > >> >
> > >>
> > >> _______________________________________________
> > >> rules-users mailing list
> > >> rules-users(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/rules-users
> > >>
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:17 a.m.
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(a)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(a)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(a)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(a)lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
>> > >> >
>> > >>
>> > >> _______________________________________________
>> > >> rules-users mailing list
>> > >> rules-users(a)lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>> > >>
>> > > _______________________________________________
>> > > rules-users mailing list
>> > > rules-users(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>> > >
>> >
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Atentamente,
______________________
Felipe Piccolini Marfull
Jefe de Proyectos
Agustina 1141 Piso 8-B
Santiago
Fono +(56 2) 68830837
E-mail felipe.piccolini(a)bluesoft.cl

12:19 p.m.
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(a)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(a)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(a)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(a)lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
>> > >> >
>> > >>
>> > >> _______________________________________________
>> > >> rules-users mailing list
>> > >> rules-users(a)lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>> > >>
>> > > _______________________________________________
>> > > rules-users mailing list
>> > > rules-users(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>> > >
>> >
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
4:43 p.m.
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(a)gmail.com <mailto:ydewit@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(a)codehaus.org
>>> <mailto:mproctor@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(a)codehaus.org
>>> <mailto:mproctor@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(a)lists.jboss.org
<mailto:rules-users@lists.jboss.org>
>>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
>>> > >> >
>>> > >>
>>> > >> _______________________________________________
>>> > >> rules-users mailing list
>>> > >> rules-users(a)lists.jboss.org
<mailto:rules-users@lists.jboss.org>
>>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>>> > >>
>>> > > _______________________________________________
>>> > > rules-users mailing list
>>> > > rules-users(a)lists.jboss.org
<mailto:rules-users@lists.jboss.org>
>>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>>> > >
>>> >
>>> > _______________________________________________
>>> > rules-users mailing list
>>> > rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
>>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>> >
>>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
*Felipe Piccolini M.*
felipe.piccolini(a)bluesoft.cl <mailto:felipe.piccolini@bluesoft.cl>
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:25 a.m.
In my specific case, PropertyChangeListeners are useful even with the
new MVEL update dialect (which is a great feature, btw) because I am
dealing with a tree/graph where updates to an tree/graph object may
internally update related nodes. Sometimes a single object model
change may even update many other objects (in many cases multiple
properties for multiple objects). It becomes cumbersome to have to
track all that in the consequence and individually and manually modify
them.
thanks,
-- yuri
On 6/28/07, Mark Proctor <mproctor(a)codehaus.org> 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(a)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(a)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(a)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(a)lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
>> > >> >
>> > >>
>> > >> _______________________________________________
>> > >> rules-users mailing list
>> > >> rules-users(a)lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>> > >>
>> > > _______________________________________________
>> > > rules-users mailing list
>> > > rules-users(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>> > >
>> >
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:33 p.m.
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(a)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(a)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(a)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(a)lists.jboss.org
>>>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>> > >> >
>>>> > >>
>>>> > >> _______________________________________________
>>>> > >> rules-users mailing list
>>>> > >> rules-users(a)lists.jboss.org
>>>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>>>> > >>
>>>> > > _______________________________________________
>>>> > > rules-users mailing list
>>>> > > rules-users(a)lists.jboss.org
>>>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>>>> > >
>>>> >
>>>> > _______________________________________________
>>>> > rules-users mailing list
>>>> > rules-users(a)lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>> >
>>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> Felipe Piccolini M.
> felipe.piccolini(a)bluesoft.cl
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
6:41 p.m.
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(a)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(a)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(a)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(a)lists.jboss.org
>>>>> > >> >
https://lists.jboss.org/mailman/listinfo/rules-users
>>>>> > >> >
>>>>> > >>
>>>>> > >> _______________________________________________
>>>>> > >> rules-users mailing list
>>>>> > >> rules-users(a)lists.jboss.org
>>>>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>> > >>
>>>>> > > _______________________________________________
>>>>> > > rules-users mailing list
>>>>> > > rules-users(a)lists.jboss.org
>>>>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>>>>> > >
>>>>> >
>>>>> > _______________________________________________
>>>>> > rules-users mailing list
>>>>> > rules-users(a)lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>>> >
>>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>> Felipe Piccolini M.
>> felipe.piccolini(a)bluesoft.cl
>>
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
6144
days inactive
6145
days old
13 comments
3 participants
participants (3)
-
Felipe Piccolini -
Mark Proctor -
Yuri de Wit