Dirk,
Shadow Facts are needed for existential ('not', exists') and
cardinality ('collect') first order logic when using java beans. At
some point we will look into allowing for scenarios where shadow facts
are not needed.
Mark
Dirk Bergstrom wrote:
Edson Tirelli was heard to exclaim, On 12/07/06 04:18:
Would you please submit your error as a JIRA bug?
My error was a long-winded complaint about the lack of a no-arg constructor for
the object type. The "beans" I'm using don't really conform to the javabean
standard. I can file a bug asking for a friendly error message, but otherwise
the error was my fault.
What I really want is the ability to turn off ShadowFacts on a per-class basis.
For one of my classes they're doing nothing but consuming memory and CPU, with
no benefit to me. Is there a JIRA for that, if not, I'll be happy to file one.
Dirk Bergstrom wrote:
I just finished a big refactoring/rewriting, fired up my application with the
latest code from Trunk, and got a nasty error about shadow facts...
Edson Tirelli was heard to exclaim, On 12/03/06 15:05:
But, if you have a pattern in your application that, lets say, always
retract objects from the working memory, changes its attributes and
assert the object again, :) then you don't need ShadowFacts... but I
think this use case is not a real use case... is it? :)
Yes, it is.
I am doing almost exactly that. In my case, I have a hundred or so objects of a
specific type that I cycle through the WM with assert/fireAllRules/retract (and
another few hundred objects of two different types that stay in the WM all the
time). I do this assert/retract dance because there is no value in having them
in the memory once I've checked their compliance with the rules -- I need to
update them with current data before running the rules again.
So creating a ShadowFact for each one after I retract it does nothing for me.
Well, except for crashing my system.
Edson Tirelli wrote:
Regarding the feature, right now it is mandatory, but I was
talking to Mark to make it optional. Unfortunally Shadow Facts are
one of those necessary evils. If you ever change a fact attribute
in your network, that fact needs a shadow fact. So, unless you use
the engine simply as a discrimination network, you will need them,
but the idea is to make them optional and better yet on an object
type basis, in a way that users can turn it ON only for those types
where it is really needed.
This would be very useful for me. I have three types, two of which stay in the
WM, and get changed (I have PropertyChangeListeners on them), and one which is
asserted and retracted. I'd like to turn off shadow facts for the third type.
