Open daisylb opened 6 years ago
It is worth pointing out that this work will depend on work for #3, which will also decrease the verbosity of some of the non-R
examples a bit.
As an aside, lookups (__gt
, __in
etc) could also be supported. This could be done with each one being a rule object of its own that takes a property
and a value_or_function
, since they'd need to do one thing for Q
lookups and another for Python-land checks, and rule objects are already a mechanism for doing that. My intention is not to do that at first though, since we haven't encountered a need for testing anything other than equality yet.
bridgekeeper.rules
should expose aR
class, with an API similar todjango.db.models.Q
.This class would take keyword arguments, with either constants, functions that take a user, or other Bridgekeeper rules as values.
This class should take keyword arguments, where keys are attribute names (traversing relationships with
__
where applicable), and values are either database values, functions that take a user, or (where the target attribute is a relationship) another Bridgekeeper rule object.As an example of what this might look like, here's a couple of snippets from the documentation, alongside the equivalent rule expressed in terms of
R
.