- cleanup the code, rename symbols for better readability
- drop dead code
- support for optionally showing empty template trace nodes
- display node path for source nodes
Expand macro passes the rule's input to nested macro calls.
This adds the macro input as the dependency of the rule's input.
As a result, incremental processing starts working in some cases.
RulePlanHandler does not rely anymore on fixed total order of
input nodes in a given rule template. An update constitutes a list
of rules/reqs generated for a pair template+input node.
All hacks that use sets of rule IDs removed.
Also, support for "new" and "dropped" rules removed, incremental algorithm
no longer supported.
Refactor supervisor/feedback consumer to support feedback basis.
Track (in)validated rules tags in RulePlanHandler.
Both (in)- and validated rules cause associated feedback to be cleared.
Disable passing SessionToken in WatchingIncremental strategy;
this forces the correct journal recording but turns off incrementality.
Optionally produce partial program in incremental mode.
A partial program includes all "static" rules plus the "required closure"
of all changed nodes.
Produce program for required nodes unconditionally.
Mark all rule updates as validated only if exlicitly asked for it.
Enable recording the dependencies while expanding macro.
Rename/refactor operations in UpdatesRecorder to reflect the intent
of adding the dependencies.
Invalidated and introduced nodes are collected by UpdatesRecorder.
If either set is not empty, a walk of the input is triggered.
Also, drop invalidated flag in RulesPlanHandler.
Introduce invalidated flag to program producer to control whether to
only process invalidated nodes in incremental mode.
Update validated flag in RulesPlanHandler to reflect the finalized
state, after the plan has been built.
Refactor ProgramProducer/Factory to avoid enumerating the source
root in case no changes have been detected (in incremental mode).
Avoid relaunching program in case the producer did nothing.
The idea to use "tracking" cache to save on typechecking operations is obsolete.
There is conflict of responsibilities with UpdatesRecorder,
which is to be solely relied upon for all things related to tracking changes.
Enable rule index to be updated during rules application.
Make RuleProcessingSession depend on AspectClique.
Enable updating of rule/macro/query indices.
Fix rule basetag generation to coincide with templateName
Needed for PrincipalStore (occurrence cache) which uses
info about occurrence source rule template name.
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).
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.
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
Fedor Isakov