Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

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. 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 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 are Like Databases

You should beware that you don't treat persistent variables the same way you treat regular variables. In particular, take note that persistence implies that the values for persistent variables are stored in a database. You cannot copy a persistent variable by reference, only by value. Use caution when manipulating large data structures in persistent variables since you may end up copying the values multiple times, making your program very slow.

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.
  • 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.

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. 

  • No labels