3:32 a.m.
Hi everyone,
Do you know if it is possible to insert/modify/retract facts in a
working memory event handler?
Here is my use case actually: I want my users to be able to write rules
like "When ... Then retract X" without having to bother with the
consequences of retracting X on the other objects of the sessions (some
of them might be retracted as well). These consequences can be expressed
by rules, but I would like them to be kind of "part of the framework"
and it would be easier for users if those rules were implicitly defined.
Many thanks in advance for any hint,
Best regards,
Bruno.
3:43 a.m.
Would the other retractions be automatically provided for by Drools' Truth
Maintenance?
Otherwise, passing a StatefulKnowledgeSession to a WorkingMemoryEventHandler
subclass and invoking it's methods should, IMO, not be an issue.
Have you tried it and experienced issues?
On 6 December 2010 09:32, Bruno Freudensprung <bruno.freudensprung(a)temis.com
wrote:
Hi everyone,
Do you know if it is possible to insert/modify/retract facts in a
working memory event handler?
Here is my use case actually: I want my users to be able to write rules
like "When ... Then retract X" without having to bother with the
consequences of retracting X on the other objects of the sessions (some
of them might be retracted as well). These consequences can be expressed
by rules, but I would like them to be kind of "part of the framework"
and it would be easier for users if those rules were implicitly defined.
Many thanks in advance for any hint,
Best regards,
Bruno.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:37 a.m.
Hi Michael,
Thanks for you answer! Following you suggestion I've taken a look at at
"logical insertions" and on one hand I have to say that it looks like
what I need, but on the other hand it is not clear to me how to
"implement it".
If you have some time to take a look, here are the objects in my session:
- one T object (something that can be considered as a "type" object)
- many I objects (something that can be considered as "instance"
objects), I objects have one "type" field beeing a T (there is no link
from T to Is)
Those facts are inserted into the session and I have the impression that
we are not speaking here of logical insertions: they have to be here, it
is the input data the user has to write rules on.
The user can decide to retract the T object: in this case all I objects
have to be retracted as well.
The user can decide to retract some I objects: when all of them have
been retracted, the T object should be retracted as well.
The first "solution" I imagined was to have high-salience rules:
rule "1"
when
t : T
not I(type == t)
then
retract t
rule "2"
when
i : I(t : type)
not Type (this == t)
then
retract i
The other solution I imagined (that I have not tried) was to retract
facts using a WorkingMemoryEventHandler.
However as I am a Drools' absolute beginner (not only to Drools, but to
the rule paradigm itself), I was wondering what is the "most natural
way" for you guys to implement that behavior :-).
Bruno.
Michael Anstis a écrit :
Would the other retractions be automatically provided for by
Drools'
Truth Maintenance?
Otherwise, passing a StatefulKnowledgeSession to a
WorkingMemoryEventHandler subclass and invoking it's methods should,
IMO, not be an issue.
Have you tried it and experienced issues?
On 6 December 2010 09:32, Bruno Freudensprung
<bruno.freudensprung(a)temis.com <mailto:bruno.freudensprung@temis.com>>
wrote:
Hi everyone,
Do you know if it is possible to insert/modify/retract facts in a
working memory event handler?
Here is my use case actually: I want my users to be able to write
rules
like "When ... Then retract X" without having to bother with the
consequences of retracting X on the other objects of the sessions
(some
of them might be retracted as well). These consequences can be
expressed
by rules, but I would like them to be kind of "part of the framework"
and it would be easier for users if those rules were implicitly
defined.
Many thanks in advance for any hint,
Best regards,
Bruno.
_______________________________________________
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
https://lists.jboss.org/mailman/listinfo/rules-users
4:54 a.m.
Hi,
I'm new too, so please mind the cracks on the road inexpertly paved
with good intentions:
2010/12/6 Bruno Freudensprung <bruno.freudensprung(a)temis.com>:
The first "solution" I imagined was to have high-salience
rules:
rule "1"
when
t : T
not I(type == t)
then
retract t
rule "2"
when
i : I(t : type)
not Type (this == t)
then
retract i
That looks like a drools retelling of the chicken and egg problem to
me: how do you intend to insert new Instances or Types ?
From the logical point of view, why do you need to retract
unreferenced facts? Do you see performance issues from too many facts?
Gabor Szokoli
5:19 a.m.
Hi,
Yes, I see what you mean! That's why, before starting, I wanted to make
sure that I was not completly mistaken ;-).
Please find my answers below.
Bruno.
Gabor Szokoli a écrit :
That looks like a drools retelling of the chicken and egg problem to
me: how do you intend to insert new Instances or Types ?
Yes, I must admit I've had the same feeling too :-).
I have an XML containing those Instances (many) and Types (few and
"unique"), all of them being XML elements :
<type id="1"/>
<type id="2"/>
<instance typeRefid="1" />
<instance typeRefid="1" />
<instance typeRefid="2" />
<instance typeRefid="2" />
<instance typeRefid="2" />
and I simply plan to read my XML and add the corresponding objects into
the session, then to fire the rules.
>From the logical point of view, why do you need to retract
unreferenced facts? Do you see performance issues from too many facts?
Well... I wanted to delegate the whole "logic" to Drools and I
imagined
that I could "listen" to Drools' WorkingMemory's retraction events in
order to remove the corresponding elements from the input XML.
Bruno.
6:25 a.m.
I think I've got your use case: you are making XSLT on steroi^W some
kind of cheese that tastes stimulating and is dense in nutrients but
is in no way controversial.
It would allow user rules for removing stuff, and have built-in rules
for transitively removing unreferenced stuff, right?
On Mon, Dec 6, 2010 at 12:19 PM, Bruno Freudensprung
<bruno.freudensprung(a)temis.com> wrote:
I simply plan to read my XML and add the corresponding objects into
the session, then to fire the rules.
Ahh, silly me, rule processing is externally initiated in Drools, it's
not some kind of perpetual event engine.
Well... I wanted to delegate the whole "logic" to Drools
and I imagined
that I could "listen" to Drools' WorkingMemory's retraction events in
order to remove the corresponding elements from the input XML.
Would a query work instead of the event listener then?
I guess it would if the list of remaining stuff is good too...
Or you could mark the unneeded stuff instead of retracting, reason
over the marks, and be able to query the marked stuff directly:
rule "orphaned Type"
when
t : T(mark != true)
not I(type == t, mark == true)
then
modify (t) {setMark(true)}
end
rule "orphaned Instance"
when
t : T(mark == true)
I(type == t, mark != true)
then
modify(i) {setMark(true)}
end
// transform your rules "1" and "2" as well to sanitize input!
query "types to delete"
t : T(mark == true)
end
query "instances to delete"
i : I(mark == true)
end
6:36 a.m.
The initially posted rules "1" and "2" are best practice. You are
using a
Production Rule Engine, and these rules are what they are made for.
Doing it in an event handler is not impossible, but it requires you to
implement logic which is (apparently) part of the application domain
("There must not be a T without at least one I." and "There must not be an
I
without its T.") and, moreover, logic which is readily available by the
Engine's
workings.
Don't reinvent the wheel, just start rolling along.
-W
On 6 December 2010 13:25, Gabor Szokoli <szocske(a)gmail.com> wrote:
I think I've got your use case: you are making XSLT on steroi^W
some
kind of cheese that tastes stimulating and is dense in nutrients but
is in no way controversial.
It would allow user rules for removing stuff, and have built-in rules
for transitively removing unreferenced stuff, right?
On Mon, Dec 6, 2010 at 12:19 PM, Bruno Freudensprung
<bruno.freudensprung(a)temis.com> wrote:
> I simply plan to read my XML and add the corresponding objects into
> the session, then to fire the rules.
Ahh, silly me, rule processing is externally initiated in Drools, it's
not some kind of perpetual event engine.
> Well... I wanted to delegate the whole "logic" to Drools and I imagined
> that I could "listen" to Drools' WorkingMemory's retraction events
in
> order to remove the corresponding elements from the input XML.
Would a query work instead of the event listener then?
I guess it would if the list of remaining stuff is good too...
Or you could mark the unneeded stuff instead of retracting, reason
over the marks, and be able to query the marked stuff directly:
rule "orphaned Type"
when
t : T(mark != true)
not I(type == t, mark == true)
then
modify (t) {setMark(true)}
end
rule "orphaned Instance"
when
t : T(mark == true)
I(type == t, mark != true)
then
modify(i) {setMark(true)}
end
// transform your rules "1" and "2" as well to sanitize input!
query "types to delete"
t : T(mark == true)
end
query "instances to delete"
i : I(mark == true)
end
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:37 a.m.
Hi Wolfgang,
Thank you for your advice! Indeed, this logic is part of my application
domain.
Best regards,
Bruno.
Wolfgang Laun a écrit :
The initially posted rules "1" and "2" are best
practice. You are using a
Production Rule Engine, and these rules are what they are made for.
Doing it in an event handler is not impossible, but it requires you to
implement logic which is (apparently) part of the application domain
("There must not be a T without at least one I." and "There must not
be an I
without its T.") and, moreover, logic which is readily available by
the Engine's
workings.
Don't reinvent the wheel, just start rolling along.
-W
5104
days inactive
5104
days old
7 comments
4 participants
participants (4)
-
Bruno Freudensprung -
Gabor Szokoli -
Michael Anstis -
Wolfgang Laun