[Feature][Performance] Use object instead of dict

[filwaline]

While using vakt, i found that it's hard to build a common inquiry, and since vakt does not support dynamic attribute retrieve, so i have to provide all information to make an Inquiry, and there is where waste coming, some information are not necessary but computed anyway.

If vakt build inquiry using object, then we can make some computing delay or never execute by define them with @functools.cached_property

For example, policy A require attribute subject.is_friend_of_my_friends(assume it is heavy computing)

• policy A missed, then this computing never executed
• policy A hited, just normal and go
  • some other policies require subject.is_friend_of_my_friends too, and cache will return, no more extra computing

And this make vakt more like Attribute-Base-Access-Control, isn’t it?

[kolotaev]

Actually, a good catch for situations like this.

We can provide a check on the Matcher level: if an Inquiry's attribute is callable or is an object (with some interface) then we can call it and obtain the value, otherwise we just grab the value itself.

The caching will be an opt-in on the inquiry-provider side and not baked into vakt anyway.

Meanwhile while this feature is not there you can create an Inquiry generator on your side that will calculate the Inquiry dynamically and use cached results if needed. The downside is that you'll need to calculate the attribute values for each Inquiry at least once - depending on the implementation and the use-case it can be reasonably performant.

Does it sound good to you?

[filwaline]

Yes, RulesChecker is what i actually aim for, not Inquiry, a new(or updated) checker that allow inquiry's attributes be callable or object will be good enough.

---

Meanwhile while this feature is not there you can create an Inquiry generator on your side that will calculate the Inquiry dynamically and use cached results if needed. The downside is that you'll need to calculate the attribute values for each Inquiry at least once - depending on the implementation and the use-case it can be reasonably performant.

Not sure what a inquiry generator like, and why you think it is a solution.

[kolotaev]

Yes, RulesChecker is what i actually aim for

That is correct. I meant exactly this.

Not sure what a inquiry generator like, and why you think it is a solution.

It's some sort of a function/class-method that takes some incoming parameters and returns an Inquiry object: let's say it takes Max username as input and returns an inquiry for Max as a subject and a is_friend_of_my_friends boolean attribute (with a heavy computing done). So this inquiry has all the attributes computed and on the vakt's checker level all the policies will see the already computed value of is_friend_of_my_friends. On an inquiry-generator level you can leverage the caching or whatever in order not to calculate is_friend_of_my_friends for the same user each time a new request is coming in.

[filwaline]

Well, there heavy computed attributes maybe dynamic and requires re-eval every time, I am not meant cache them for later re-use.

If they are provide as a computed property, in the same round policies evaluation, they maybe hits multiple times, so cached_property can prevent re-eval in the same round. (Not a business that vakt should mind)