-
Notifications
You must be signed in to change notification settings - Fork 46
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
Roles should be scoped within Relations #107
Comments
Further, we want to add the ability to override a role in a sub-relation using |
Corner cases:
|
There will also be a syntax change to Graql, @flyingsilverfin : When you define roles in a
You will refer to the roles being played by an
When a relation inherits a role from a parent relation, such as the role
You must can only refer to the
|
Can you aggregate all the comments (both of yours and mine) into a clear breakdown of changes included in this issue, in the issue description, @flyingsilverfin? All this should be one big change that goes in together. |
@haikalpribadi sure - do you think inheriting roles is a prerequisite? the change is going to be big already, might be worth breaking it down where we can and doing first inheritance, then making the syntax changes. |
Note that some of the changes will be in Graql, and some are in Grakn Core. You can break them into the respective smaller task and put the issue in the correct repo, if that helps you. Make sure to reference them in this issue description - have a checklist of complete ones would be very useful. |
## What is the goal of this PR? To being changes decided in #107 , we modify the grammar to have `type_scoped` as well as the default `type` that is unscoped. To make this make sense at the object level, we create a new object called `Label` that we will soon remove from `core` and `client-java` that can be scoped and unscoped types - Labels are now used throughout Graql to represent types. Where possible, we provide helper methods that consume `String`, creating the required `Label` objects internally and passing the Labels as required. ## What are the changes implemented in this PR? * Create `Label`, a class holding the combination of scope + name. `scope` may be null * The parser creates `Label` classes instead of strings from `label_ref`, `label_scoped`, and `label` rules * `Compute` targets such as `of` and `in` require `Label` objects under the hood, though we provide convenience helpers that take strings and wrap them as `Label` where possible
Typo in comment by @haikalpribadi #107 (comment)
|
## What is the goal of this PR? To being changes decided in #107 , we modify the grammar to have `type_scoped` as well as the default `type` that is unscoped. To make this make sense at the object level, we create a new object called `Label` that we will soon remove from `core` and `client-java` that can be scoped and unscoped types - Labels are now used throughout Graql to represent types. Where possible, we provide helper methods that consume `String`, creating the required `Label` objects internally and passing the Labels as required. ## What are the changes implemented in this PR? * Create `Label`, a class holding the combination of scope + name. `scope` may be null * The parser creates `Label` classes instead of strings from `label_ref`, `label_scoped`, and `label` rules * `Compute` targets such as `of` and `in` require `Label` objects under the hood, though we provide convenience helpers that take strings and wrap them as `Label` where possible
is this fully implemented, if so should this issue be closed, If not how about a description of what is and is not working and why are the changes to the language not documented in the TypeDB release notes |
they were documented in the first 2.0 graql/typeql release notes, but you're right it should be closed |
Problem to Solve
Roles are currenty globally scoped, which not only makes naming more difficult, but also increases complexity of Graql as we can share roles across unrelated parts of the type hierarchy.
Proposed Solution
We will scope roles to belong to relations. In other words, roles will be scoped to a relation and not live independently. This will making naming much simpler, as roles will be interpreted within the context of the relation name the user is providing.
The text was updated successfully, but these errors were encountered: