The Jess manual warns against using queries on the *RHS* of a rule
unless you really understand what you're doing; using them on the LHS
of a rule is even worse. You need *really* strong super hacker mojo.
All kinds of odd things can happen, and you have to have a very deep
understanding of how Jess works to understand the issues.
Queries are intended for when the rule engine isn't even running;
they're a way to do reporting after your rules are all through.
I'd recommend an alternative but I can't quite understand what you're
trying to do. You could certainly replace your query and loop with a
pattern and simple rule firings; perhaps you'd want to use the
"exists" conditional element.
On Feb 13, 2009, at 6:21 PM, Neelakantan Kartha wrote:
The following code (see below) behaves in different ways in Jess 7.1
depending on whether a piece of code (that is never called) is
present
or not.
Comment and uncomment the defquery getClasses to see different
results.
1. What is the reason for this behaviour? Is it because the order in
which the defQuery getSlotValue gets called in relation to firing of
the
rule
obtained-beforehand gets changed by the addition of the defquery
getClasses?
2. Is there some recommended way to get rid of such problems? Or is
the
recommended way not to use run-query* in the LHS of rules?
---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences Phone: (925) 294-2154
Sandia National Labs
PO Box 969, MS 9012 [email protected]
Livermore, CA 94550 http://www.jessrules.com
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [email protected]'
in the BODY of a message to [email protected], NOT to the list
(use your own address!) List problems? Notify [email protected].
--------------------------------------------------------------------
