You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
as policies get more complex, we will see the need for more structured data, that could be queried from datalog. In particular, arrays and maps would make policies more flexible.
A few issues here:
they require a list of operators supporting them
the current syntax already uses [ ] for sets, which would be the common syntax to expect for arrays
The text was updated successfully, but these errors were encountered:
use { <key>: <value> } for maps, where <key> and <value> can be an arbitrary datalog term
use {} for sets
Possible issues: syntax ambiguity between parameters and sets (eg: {true}). we could remove set literals and provide set operators on lists (and remove Set from datalog), or keep Set, but only allow constructing it through a .toSet() method on lists.
New operators
.get(<key>) on maps (where key can be any datalog term
.get(<index>) on arrays (where index has to be a positive integer)
.get() on a map would return null for a key that is not in the map. .get() on an array would throw an error on a key that is not an integer, and null if they key is negative or not in the array
Lifting restrictions
lists and maps could be nested
lists and maps could contain variables? not sure, we should investigate
as policies get more complex, we will see the need for more structured data, that could be queried from datalog. In particular, arrays and maps would make policies more flexible.
A few issues here:
[ ]
for sets, which would be the common syntax to expect for arraysThe text was updated successfully, but these errors were encountered: