-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include reasoning logic when restricting db #767
Conversation
This is meant to solve Story 1 from https://github.com/fluree/core/issues/102 |
Accepts a rules graph with :reasoner-rules in the opts and a rules db with :reasoner-rules-db. Both of these keys expect a list, but since our reasoner only supports one rule source currently, the list should only have one element. If both a graph and a db are provided, it will use the db.
If anyone has ideas on how to get a db of rules from just an alias when using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall! I noted a couple of very minor formatting things to address just in the interest of minimizing whitespace churn in the future. Thanks!
db) | ||
time-travel-db (-> (if t | ||
(<? (time-travel/as-of policy-db t)) | ||
policy-db)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love these more descriptive var names!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the new policy PR, this has changed a little bit so the above wouldn't be compatible. Now you compose dbs, instead of a bunch of if conditions in the API. In this case if you wanted a db to be policy-wrapped, you'd call that API first explicitly. This no longer looks for this option in a regular query.
Also if a query is wrapped in a verifiable credential, there is a new explity query API for that... so this check won't be done always.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like that PR has failing checks, should I wait for it to be merged and then adjust this PR to work with it?
No description provided.