Unique attribute ownership

[flyingsilverfin]

For the title of this PR: please follow the grammatical rules of a usual publication title, without capitalisation (except for the first letter). Thus, the title should NOT CONTAIN CODE: no dots, no parentheses, no backticks, no brackets, etc. It needs to be distinctive (not detailed) and succinct (not lengthy). Details of this PR will go in the description. For the description of this PR: please replace every line in curly brackets ( { like this } ) with an appropriate description following the guidance. Finally, please remove this paragraph.

What is the goal of this PR?

{ In the form of a paragraph (only use bullet points if strictly necessary), please describe the goal of this PR, why they are valuable to achieve, and reference the related GitHub issues. This section will be automatically compiled into the release notes, so please:

• describe the impact of the change in this PR to the user of this repository (e.g. end user, contributor, developer).
• describe the new product behaviour in present tense, and the old behaviour and how it's been changed in past tense.
• Use the Royal We: "We" made changes, not "I" made changes. }

What are the changes implemented in this PR?

{ Please explain what you implemented, why your changes are the best way to achieve the goal(s) above. Please describe every method, class and package, by explaining:

• its responsibility,
• how it's expected to behave, and
• how it relates to the adjacent methods/classes/packages it interacts with.

This would allow the reviewer to understand your intentions in the code much better. If you're adding new classes, make sure these explanations are also included in the class header comments. Last but not least, please reference the GitHub issues to be automatically closed, such like 'closes #number'. }

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• This change is trivial and does not require a code or architecture review.

Code

• Packages, classes, and methods have a single domain of responsibility.
• Packages, classes, and methods are grouped into cohesive and consistent domain model.
• The code is canonical and the minimum required to achieve the goal.
• Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• The code is algorithmically efficient and scalable for the whole application.

Architecture

• Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• Any required build and release automations are updated and/or implemented.
• Any new components follows a consistent style with respect to the pre-existing codebase.
• The architecture intuitively reflects the application domain, and is easy to understand.
• The architecture has a well-defined hierarchy of encapsulated components.
• The architecture is extensible and scalable.

[flyingsilverfin]

@haikalpribadi do you think we should use a generic annotations block that can be any annotations, and then do the validation once we construct the TypeQL objects (see the commented annotations above, which we would apply using:
as OWNS type (as type)? annotations

In the future we will have long list of annotations (range, cardinality, regex, etc.) that are possible, but only some will be applicable to owns, some will be applicable to plays only, some will be applicable to the variable directly... given this I think we should have owns_annotations separate, then add over time.

[haikalpribadi]

What if we can provide more than one annotation? 🤔

Also, I think the it should be annotation_own and annotation_relation, no?

[flyingsilverfin]

Yeah i think annotation_owns makes more sense - was thinking that grouping it as "owns" first was easier to read but actually is less consistent.
I think it would be on the constraint name eg. annotation_owns and annotation_relates rather than suggested annotation_own and annotation_relation though.

The proposed mechanism does allow us to provide more than one annotation, for example @unique @cardinality(...) would be fine. The alternative is inline:

OWNS type ( AS type )? ( ANNOTATION_KEY )? ( ANNOTATION_UNIQUE )?

which also works but will overflow the line and isn't as nice to read.

[haikalpribadi]

Why the overflow? You mean the line becomes too long horizontally?

[flyingsilverfin]

yes

[haikalpribadi]

why not wrap it in another rule? like what you had before but better named?

[flyingsilverfin]

you mean the entire row for type_owns_constraint, or just keep the OWNS type as is and add a new annotations_owns = ANNOTATION_KEY )? ( ANNOTATION_UNIQUE )? similar to what I suggested?

[krishnangovindraj]

(annotations_owns = ANNOTATION_KEY )? ( ANNOTATION_UNIQUE )? enforces an order on the annotations
@key @unique parses, whereas @unique @key does not.

[krishnangovindraj]

In the case where both @key and @unique are present, this will silently ignore the @unique. This results in the right behaviour, but isn't faithful to what's been written

[flyingsilverfin]

Replaced by #273