Page Comparison

...

This example was inspired by this commit, and finishes an attempt to follow the best practice from the “Managing Pico Lifecycle” document.

Initializing entity variables on ruleset installation

It is a common practice to react to the wrangler:ruleset_installed event with a rule that gives entity variables an initial value for the pico in which the ruleset was just installed for the first time.

An example of what this looks like:

  rule initialize {
    select when wrangler ruleset_installed where event:attr("rids") >< meta:rid
    fired {
      ent:apps := built_ins()
    }
  }

Things can go wrong here.

First, it is essential to guard the selection with this where clause. Otherwise, as more rulesets are installed into the same pico, this rule would select on those and re-initialize ent:apps to the initial value. If in the meantime, it had been changed, those changes would be erased!

Second, if the pico’s owner installs the same ruleset a second time, ent:apps will also be re-initialized to the initial value.

To avoid this second problem, it is best practice to guard against it with code like this:

rule initialize {
    select when wrangler ruleset_installed where event:attr("rids") >< meta:rid
    if ent:apps.isnull() then noop()
    fired {
      ent:apps := built_ins()
    }
  }

This cautionary tale was inspired by this commit which followed an emergency fix to manually restore ent:apps to a value that had accumulated over time between the first installation of a ruleset into a pico and a second, ill-advised, installation months later.