Fix rule basetag generation to coincide with templateName
Needed for PrincipalStore (occurrence cache) which uses
info about occurrence source rule template name.
Allows to carry logically connected information in one object.
Needed for subsequent changes to ConstraintOccurrence, which
must have better information on source rule: rule template name.
Used by occurrence cache.
It's important that program that uses occurrences from cache
shouldn't include rules that could produce their duplicates.
So implementation of occurence cache includes 2 parts:
on reactor level & in ProrgramFactory.
When RuleBuilders are produced, cache is queried whether
there're already occurrences associated with the rule template
in question. If so -- then those RuleBuilders are not included
into the program (as well as all RuleBuilders required by it).
CachedOccurrencesProcessing simply activates occurrences
passed to it as input before proceeding with 'main'.
Use it instead of PreambleProcessing (that works with journal).
This should help if 'main' doesn't lead to duplicate activations
of these occurrences. So coderules program must be aware of
occurrence cache and should not include rules for cached occ-s.
Get information on invalidated nodes from EvaluateStep & incr processing
instead of UpdatesRecorder, which has only partial info and can't handle
all cases.
Relevant for Incremental strategy.
Allows to more precisely track invalidated types of nodes.
Type of node is invalidated if rules with this origin
were invalidated during incremental processing.
Avoid evaluating templates and producing rules on null
input and all required closure of this input, which effectively
constitutes the static collection of rules that are only
dependent on chosen aspect clique.
Avoid calling template's code if cached evaluation results are
not invalidated.
Keep information on required nodes (dependencies) together with
the list of produced rule ids.
TemplateApplicationSession allows to invoke require with the
input node as the first parameter, which is then forwarded as
a "requirement" (TODO: rename to dependency).
The use of ProgramProducer and other stuff have new requirements.
The program is now produced incrementally, with UpdatesRecorder
playing a major role in keeping track of changes.
Move invalidation logic inside UpdatesRecorder from elsewhere.
Drop type parameters.
Avoid recording dependencies for null input.
ProgramFactory: always process input, not only the first time
A query may be invoked without the input node, thus dispatching
macros by the specified concept. The concept must be taken into
account when calculating the "diff", so that the old (stale)
rules don't override the updated ones.
Fedor Isakov