Sorry, but I simply fail to understand why the newly arriving object A2
can't be used in a simple method where you copy all its field values
into A1, followed by a call to rete.updateObject().
It'd be interesting to learn which strategy is preferable: either a
single call to updateObject( Object ) after indiscriminately copying all
fields or individual copy operations, for differing fields only, each
followed by a call to the two argument form of updateObject(). If you
know what changes to expect, then this might also help to decide either way.
Regards
Wolfgang
Will Edwards wrote:
That sounds exactly right, we did indeed try and modify the OBJECT slot, and
yes it failed in a pretty emphatic way. I'm pretty sure we got it right
because other slot modifications using the same mechanism worked correctly.
We're currently getting our license and will work on this integration the
moment we do.
Thanks a lot,
Will Edwards
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ernest Friedman-Hill
Sent: Tuesday, December 11, 2007 9:46 AM
To: jess-users@sandia.gov
Subject: Re: JESS: Updating shadow facts from object copies
Hi Will,
There are three parts of this problem:
1) Given the copied object, identifying the existing object that
corresponds to it. This could be tricky unless the objects have some
kind of id. You didn't mention this being a problem, so I'm going to
assume it's solved.
2) Updating the shadow fact so that it refers to the new object.
Technically this shouldn't be hard -- the OBJECT slot could
theoretically just be modified like any other slot. Unfortunately
there's going to be a problem: if you tried this on a static
definstance (which I'll assume yours are), Jess would try to set the
OBJECT property of the object itself, and presumably this would fail
spectacularly.
3)Besides the OBJECT slot, Jess also keeps a map which associates
each definstanced object with its shadow fact; that's so Jess can
quickly handle propertyChange events, undefinstance() calls, etc.
where you pass in the object and Jess needs to find the fact. There's
no public API for changing this map directly.
Now, the nice thing is that Jess is licensed in source code form, and
you can make your own modifications. Appropriate mods for this would
really be pretty simple.
To handle (3), you could add a method something like this to jess/
DefinstanceList.java
void useNewObject(Rete engine, Object newObject, Object oldObject) {
synchronized (engine.getWorkingMemoryLock()) {
Fact fact = (Fact) m_definstances.get(oldObject);
if (fact != null) {
m_definstances.remove(oldObject);
m_definstances.put(newObject, fact);
}
// else maybe throw a JessException
}
}
Also add a package-protected method to Rete which forwarded calls to
m_factList.
To handle (2), you'd want to add special cases to jess/FactList.java
for a property named OBJECT. In modifyDefinstancedFact(), you'd want
to call your method on Rete to change the lookup object instead of
setting the object's property the way it does now. You'd also want to
call modifyRegularFact directly from modifyDefinstanceFact() to
change the OBJECT slot itself.
On Dec 11, 2007, at 8:38 AM, Will Edwards wrote:
Wolfgang is correct, we have a single Rete instance. He is also
correct in
that we can always obtain a reference to the original object via
the shadow
fact, or some other way.
The problem is that when an update happens to an object a new copy
of the
updated object is passed. So, we have two physical objects that
represent
the same logical piece of data, say A1 that is already in Rete as a
shadow
fact, and A2 the updated version of A1 that has just been passed to
us.
My question was: what is the best, or simplest, way to update Rete
with the
new object.
Thanks.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:owner-jess-
[EMAIL PROTECTED] On
Behalf Of Wolfgang Laun
Sent: Tuesday, December 11, 2007 4:48 AM
To: jess-users@sandia.gov
Subject: Re: JESS: Updating shadow facts from object copies
I have understood Will's problem to be within a single Rete object.
Basically, the Rete.add() method returns a reference to the created
jess.Fact. As a shadow fact in good standing it'll have a slot OBJECT
containing a reference to the original Java object. "Therefore, the
original object is always easily available." (The Jess Manual, 5.3.2)
Hal Hildebrand wrote:
Wouldn't the fact id be (potentially) different in different
instances of the rules engine? I believe these are assigned in
declaration order, so unless every instance is defining instances in
precisely the same order, then you'd end up with the same logical
fact having different ids in different VMs.
FWIW, there's a good paper by someone who did something remarkably
similar: www.waset.org/pwaset/v4/v4-18.pdf
Myself, I've taken another route, which is using shadow facts for
everything I want distributed. The facts all have generated UUIDs,
so there's no issues with locally generated ids in a distributed
system. Then it's a fairly simple matter to translate to the local
facts when the shadow changes and vice versa.
On Dec 10, 2007, at 1:07 PM, Will Edwards wrote:
We're attempting to integrate a JavaSpaces implementation with Jess.
When an object changes in the JavaSpace we receive a notification
that the
object has changed and a copy of the changed object which we want to
add or
modify as a Jess shadow fact in the rules engine.
Our problem is that in this environment we do not get a reference to
the
original object but a new (by value) copy of the object. So, we
want to
modify the existing Jess fact with the new copy. Assuming we have
the
FactIDValue (from the original rete.add) is there a reasonably
simple way to
do this?
Currently we are using a FactFilter to get the existing object, call
rete.remove() to remove the old copy and then rete.add() with the
new copy.
This is of course prone to potential race conditions, etc.
What we would like to do is use modify() or updateObject() but both
of these
seem to require that the original object reference be maintained.
Thanks in advance.
--------------------------------------------------------------------
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] .
--------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
--------------------------------------------------------------------
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 owner-jess-
[EMAIL PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
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 owner-jess-
[EMAIL PROTECTED]
--------------------------------------------------------------------
---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
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]
--------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
