Comments (4)
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.
Related Issues (20)
- Allow nested negation and universal quantification in rules HOT 3
- Allow binding of ownerships to anonymous variables in query patterns
- Ignoring repeated constraints
- Support modifiers (at least the limit) in all type of queries HOT 3
- Using standard form for numeric literals throws an error when parsed HOT 5
- [Feature Request] More operators and basic functions HOT 1
- Allow negations and disjunctions without an exterior binding
- Unary negation
- Factor out typedb-common and typedb-proc-macro crates
- Sanitize rust macros to avoid forcing user's environment
- Give relation and value constraints explicit keywords
- Add deployment tests for Cargo and Pip snapshots
- Introduce a syntax element to explicitly end a query string
- Plays-as overrides break schema export
- Fetch: add a way to project an item into a list of attributes by label HOT 1
- Introduce syntax for interface covariance HOT 2
- Composition of interface implementations as high-level abstractions (traits)
- Allow casting of type variables to value variables HOT 3
- Ability to define metadata for types without replicating the information across all type instances
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typeql.