Wolfgang, That is certainly an approach we'd considered. We were not too enthusiastic about it though because it would mean that every object type we wanted to potentially store would have to implement the copy method, or we'd do something more generic with introspection.
Both of these seemed a bit out of line in the; work required to what we wanted to do ratio. Adding a method to the definstance list certainly seems (to me) more efficient and less burdensome on the general developer community. When we implement this solution I will be sure to do some benchmarking and let everyone know if there are any surprises. Thanks a lot, Will -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang Laun Sent: Thursday, December 13, 2007 1:38 AM To: [email protected] Subject: Re: JESS: Updating shadow facts from object copies 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: [email protected] >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: [email protected] >>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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
