typeql icon indicating copy to clipboard operation
typeql copied to clipboard

Make annotated constraints to apply to subtypes

Open izmalk opened this issue 1 year ago • 4 comments

Problem to Solve

To share the Unique constraint between multiple types. E.g., all cars have a unique ID (License plate number), including subtypes of car, like sedan and hatchback.

See the generic schema example below:

define 

id sub attribute, value string;

supertype sub entity,
    owns id @unique;

subtype1 sub supertype;
subtype2 sub supertype;

Current Workaround

The code above will work, but the constraint of uniqueness for the id is applied separately for every subtype.

Proposed Solution

The subtypes will share the pull of unique constrained values of id. The following insert query should return an error:

insert

$s1 isa subtype1, has id "1";
$s2 isa subtype2, has id "1";

Additional Information

izmalk avatar Jun 26 '23 16:06 izmalk

It is worth considering: would all annotations be inherited in the same way, including planned ones? I think we want to avoid having different inheritance behaviour for different annotations as that manifests as an invisible rule that users will have to learn the hard way unless they read the enitre docs. A user, having learned how one annotation is inherited, would likely assume that all other annotations are inherited in the same way. Even if we signpost any disparity well enough that it can't be missed, it still represents an additional hurdle when learning the language.

james-whiteside avatar Jun 26 '23 16:06 james-whiteside

As a quick suggestion. Being able to declare @unique and @key both when:

  • declaring ownership (local and inherited effect) but also when
  • declaring the attribute type (global effect) would be great!

lveillard avatar Jun 28 '23 13:06 lveillard

On the attribute or the attribute type?

flyingsilverfin avatar Jun 28 '23 14:06 flyingsilverfin

Attribute type. In the same way the regex and the value type is global:

define
email sub attribute,
value string,
regex "^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$",
unique;

Then, for the current behaviour (@key and @unique by scope) that could be done either: A) Exactly as it works right now, defining it in the attributeType ownership relation B) Declaring @key or @unique in sub-attributes of the original attribute and assigning the subattributes to different entities name sub attribute; name-A sub name, unique; name-B sub name, unique; => scoped uniqueness withthe advantage of only being able to define @unique and key on attributeType definition and not in two different types C) Similar but without subattibutes, just making them different attributes that are similar

This would work also for cardinality constraints, enabling typeDB users to define them globally for an attribute, or scoped.

A quick classification I have in mind:

  • value: Only global
  • unique, key: Global, scoped
  • Regex, cardinality, validations: global, scoped & chained

Where chained means being able to make it more strict on each sub-definition.

Examples

Format A (two ways to add restrictions)

define
using-auth-providers sub attribute, 
value string, 
regex "^(google|facebook|github|other_auth_provider)$";

user sub entity, 
owns using-auth-providers @card(*);

superUser sub user , #users with that need to have configured at least two auth providers and only using top providers
owns using-auth-providers @card(2,*) @regex("^(google|facebook|github)$");

Format B (restrictions only on attributeType definition)

define
using-auth-providers sub attribute, 
value string, 
regex "^(google|facebook|github|other_auth_provider)$",
cardinality *;

super-using-auth-providers sub attribute,
value string,
regex "^(google|facebook|github)$",
cardinality (2,*);

user sub entity;

normalUser sub user,
owns using-auth-providers;

superUser sub user,
owns super-using-auth-providers;

I'm probably not thinking on other alternatives and edge cases, but the key thing is to provide a way to do both global and scoped constraints somehow

lveillard avatar Jun 28 '23 19:06 lveillard