Earlier, I made note of the fact that KRL declarations do not cause side effects. 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 three types of persistent variables. (Persistent variables are currently limited to approximately 1,000,000 characters 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 app.
Entity, application, and request 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 take four forms:
- Flags. Flags store Boolean values. Operations on flags allow the flag to be set or cleared.
- Counters. Counters store numeric values. Operations on counters allow them to be incremented, decremented, and tested.
- Tr ails http://docs.kynetx.com/docs/Trails. Trails function like stacks. Operations on trails allow values to be pushed onto the trail, forgotten, and tested. (The name trail is historical. As originally envisioned, trails were used to keep track of the URLs an entity visited.)
- Literals. Literals can be numbers, strings, arrays, or maps, and admit operations on those values.