Should facts be distinct by type, are "general" facts encouraged or discouraged? #335
Replies: 2 comments
-
@douglasg14b from the performance perspective, I think this decision is insignificant, because fact type is simply yet another condition the engine is using to filter down facts in the Rete graph. All facts first go to a TypeNode that routes facts by their type to the corresponding subtree in the graph. So, matching an ExpertMessage will first go to a TypeNode where Type = ExpertMessage, whereas a Message { Sender = "Expert" } will go to a TypeNode where Type = Message and then to a SelectNode where Sender = "Expert". I think any performance differences here will be dwarfed by whatever else you do in your rules, e.g. how selective your match conditions are, the magnitude of joins, etc. |
Beta Was this translation helpful? Give feedback.
-
FWIW I personally prefer more specific facts, closer tied to real concepts in my domain in a 1:1 way |
Beta Was this translation helpful? Give feedback.
-
Is there an opinion, either for performance, semantics, patterns of use or otherwise. That facts be distinct by type, or should they be "general"?
I'm probably describing this horribly because words are hard, so before you interpret that question, let me provide an example:
Are there upsides & downsides to doing this one way or the other? Do you have an opinion on this sort of utilization of your library?
Instead of just asking this openly, I tried to consider some for myself, perhaps you can (in)validate these in addition to sharing your opinion.
Each "fact" has a type that is semantically after that fact:
MessageSender
enum) when such an constant is requiredMore general purpose facts:
Message where Sender = "Expert"
vsCustomerMessage
)Beta Was this translation helpful? Give feedback.
All reactions