Make annotated constraints to apply to subtypes about typeql HOT 4 OPEN

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.

from typeql.

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!

from typeql.

On the attribute or the attribute type?

from typeql.

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

from typeql.