In order to get an in-depth understanding of SQRL it is vital that you understand how WHERE statements affect underlying counters and rules.
Limitations on expressions in WHERE statements
In order to provide automatic counters and other similar features, we impose some limitations on the syntax you are allowed to use inside a where statement.
This is restricted to the following operations:
For most counters SQRL will only track the counts that exist in the source code. It is important to identify how counters are uniquely identified in SQRL to avoid unintentionally changing the identification of a counter (and losing all previous values).
For example the following two counters are maintained separately:
1 | LET LoginCount := count(BY SessionActor WHERE Event="login"); |
This is to be expected. LoginCount is a count of logins, while PurchaseCount is a count of purchases. Internally we track the features used in the WHERE statement and use them to identify the counter.
Using Event
directly in count() is not recommended though, because in future you may wish to add a new action "mobile_login"
, or perhaps change "login"
to "logged_in"
. Changing the constant in the Event="X"
where clause would use a new set of counters.
Instead we recommend you use additional feature:
1 | LET IsLogin := Event = "login"; |
With this change later we can safely update IsLogin.
1 | LET IsLogin := Event IN ["login", "mobile_login"]; |
In the above case since the body of the WHERE clause did not change any previous tracked counts under the "login"
event will still exist.
When you include a file with a WHERE clause every statement in that file is included with that additional expression.
This is most clearly demonstrated by taking the following combination of files:
rules/purchase.sqrl
1 | LET NumPurchaseByActor := count(BY SessionActor); |
main.sqrl
1 | LET IsPurchase := Event = "purchase"; |
To achieve the same thing in a single file, the equivalent SQRL code would be:
1 | LET IsPurchase := Event = "purchase"; |