One of the most important issues in creating effective KRL rulesets is remembering information from one user interaction to the next.
KRL declarations cannot cause side effects (i.e. they're not variable assignments). That doesn't mean KRL rule sets can't cause persistent changes that are available from one rule-set execution to another. KRL has persistent variables that can be used inside any expression in a rule set and can be changed in the postlude.
KRL has two types of persistent variables. (Persistent variables are currently limited to approximately 1MB each.)
- Entity variables. These are used to record persistent data about individuals interacting with rules. Entity variables are identified by the namespace
ent. KRL programs keep each user's persistent entity variables separate. KRL programs are multi-tenanted automatically.
- Application variables. These are used to record persistent data about the application or rule set. Application variables are identified by the namespace
Entity and application variables share the same syntax and operations. They differ primarily in the scope of their definition. An analogy might help: Entity variables are similar to instance variables, and application variables are similar to class variables in object-oriented languages.
Persistent variables can be numbers, strings, arrays, or maps, and allow operations on those values.
Historically KRL also had special persistent variables that acted as flags, counters, and trails (stacks). These are deprecated and should not be used.
The following section show how persistent variables are used in various parts of a rule.
The power of persistent variables--especially entity variables--should not be understated. Entity variables allow developers to cerate multi-tenanted application without ever having to manage user identity. The system automatically tracks user sessions and ensures that the user's data is available to the ruleset on demand.