Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Introduce unique annotation #273

Merged
merged 13 commits into from
May 3, 2023

Conversation

krishnangovindraj
Copy link
Member

@krishnangovindraj krishnangovindraj commented Mar 29, 2023

What is the goal of this PR?

We generalise the annotation syntax and parsing to be able to handle a new type of annotation: the @unique annotation, which is available only on the owns constraint:

define
person sub entity, owns email @unique;
email sub attribute, value string;

This annotation indicates that any emails a person owns must be unique to that person. It does not place any restrictions on the number of emails any given person may own.

The language builder API has also been updated to use a generalised form of any number of annotations, rather than having a particular boolean per annotation type (now, pass annotation UNIQUE or KEY instead of booleans).

What are the changes implemented in this PR?

  • Introduce annotations_owns in the grammar
  • Introduce new grammar rules for annotations: @key becomes an annotation, as does the new @unique
  • Introduce generalised annotations in the grammar and the language builders

@typedb-bot
Copy link
Member

typedb-bot commented Mar 29, 2023

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.

| RELATES type ( AS type )?
| PLAYS type_scoped ( AS type )?
| VALUE value_type
| REGEX STRING_
| TYPE label_any
;

annotations_owns : ( ANNOTATION_KEY )? ( ANNOTATION_UNIQUE )? ;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krishnangovindraj raised good point about order indendence:

OWNS type ( AS type )? (annotation_owns*)

annotation_owns = ANNOTATION_KEY | ANNOTATION_UNIQUE | ANNOTATION_CARD ...

note that now each one is optional independently and the rule is written in singular form.

private final TypeVariable attributeType;
private final TypeVariable overriddenAttributeType;
private final boolean isKey;
private final List<Annotation> annotations;
private final Annotation uniqueness;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't want to group annotations into super-types of annotations in the language for validation/restriction purposes.

@flyingsilverfin flyingsilverfin changed the title Unique annotation Introduce unique annotation Apr 3, 2023
@flyingsilverfin flyingsilverfin force-pushed the unique-annotation branch 4 times, most recently from 564aa5f to 8029783 Compare April 26, 2023 11:20
@flyingsilverfin flyingsilverfin marked this pull request as ready for review April 26, 2023 13:48
@flyingsilverfin flyingsilverfin merged commit 1a4c520 into typedb:master May 3, 2023
@flyingsilverfin flyingsilverfin added this to the 2.18.0 milestone May 22, 2023
dmitrii-ubskii added a commit that referenced this pull request May 23, 2023
## What is the goal of this PR?

We generalise the annotation syntax and parsing to be able to handle a
new type of annotation: the `@unique` annotation, which is available
only on the owns constraint: `define person sub entity, owns email
@unique;`

The `@unique` annotation has been introduced first in TypeQL Java in
#273.

## What are the changes implemented in this PR?

We update the pest grammar used in the Rust parser to mirror the changes
in TypeQL Java, and adjust the parser visitors to match.

A few drive-by fixes:
- mild refactoring prompted by Clippy;
- replaced usage of deprecated `chrono` `NaiveDateTime` builders with
up-to-date variants.
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants