Skip to content
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

Improving rewrite semantics #65

Open
Akron opened this issue Aug 30, 2018 · 0 comments
Open

Improving rewrite semantics #65

Akron opened this issue Aug 30, 2018 · 0 comments
Assignees
Labels

Comments

@Akron
Copy link
Member

Akron commented Aug 30, 2018

I am currently thinking about changing the semantics regarding VC rewrites (or rewrites in general) for Kalamar.
At the moment when a rewrite is performed by Kustvakt, e.g. by adding constraints to the VC for access restrictions, these rewrites are shown in the VC builder as normal constraints and reported as rewrites by small icons attached to the constraint (Known bug). Now if a new request is made that includes the rewritten VC, e.g. searching for another term, the VC is serialized like all rewritten constraints were created by the user. That means, in the following requests the rewrites are no longer reported as rewrites.

My idea to make rewrites more transparent to the user is: Whenever a VC is send to the backend, first it will revert all rewrites performed on this VC (depending on #51). All constraints that were rewritten will have a distinct color in the VC builder, to make clear that these constraints won't be serialized as they are. By clicking on a special button (or on the rewrite button), the rewrite report will be deleted and the constraint will be treated as a user-created constraint.

As a side effect, this is also more in line with how rewrites are serialized for queries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants