Introduce auto-generated / auto-incrementing keys

[alexjpwalker]

Problem to Solve

We want to discourage the use of IIDs and encourage the use of keys.

But right now, generating keys is a cumbersome task. Most users don't want to have to fabricate a unique ID manually for every Thing that they insert.

Current Workaround

The user must fabricate their own unique IDs somehow - or just use the internal IID.

Proposed Solution

We could introduce an auto-generate feature for our keys - at least for long valued keys. Something like:

define
ref sub attribute, value long;
person sub entity, owns ref @key @auto-generate;

then when you insert 10 person instances, Grakn automatically puts the ref instances [1..10] and attaches one to each person with a has edge.

Additional information

See also: https://github.com/graknlabs/client-java/issues/271

[lveillard]

I really like prisma's implementation: https://www.prisma.io/docs/concepts/components/prisma-schema/data-model

The way they split the @key/@id (that can be N composite keys) and the @unique is so smart!

A first idea could be to put the keys at the entity level and the @unique at attribute level

org-team sub entity,
    @key(orgId, teamId),
    owns orgId,
    owns teamId unique @default(autoincrement())

In this example we get:

• Automatic auto incremental value for teamId
• Ensuring that org-team have unique names per org

📝Missing pieces

• The @default label => (creates an instance of the attribute with that value on entity creation)
• Functions: => Functions that can be executed onWrite
• autoincrement() => Would be useful for this case but probably for other cases too
• uuid() function => This could be an alternative to autoincrement() where we generate an uuidv4

📝Why both @unique and @id/@key?

• Uniqueness is a necessary condition for an Id, but something can require being unique and not necessarily be the main/conceptual identifier of that node
• UNIQUE is a pretty standard term for this (SQL, mongo...)
• Unique fields that are not mandatory, for example an email address that we would like to be unique but maybe some users don't have it. Keys are mandatory.
• All keys should be strings or numbers, but @unique attributes could be other things

[flyingsilverfin]

TypeDB 3.0

Problem to solve

TypeDB should offer a sort of auto-generated attribute value, such as auto-increment. This should be defined at the owns level, rather than the attribute domain level.

This attribute would therefore probably not be user-insertable.

Proposed solution

We prefer the syntax of Postgres, which uses @serial. We may also differ from Postgres and SQL in that @serial is not a default value, but something that is only auto-generated and guaranteed to be unique within this type's ownership. We may also implement other types of auto-generated IDs, such as UUID.

[flyingsilverfin]

Note: auto-increment/serial falls under the domain of defaulting values in most databases

[lveillard]

A random idea:

• Rules are an example of "onRead" computations.
• Autoincrements on the other hand are an example of "onWrite" computations

If in the future, formulas will be enabled in writes for instance insert $a has numberCode MEAN($bNum,$dNum); Or computed values onWrite define timestamp sub attribute, value string, default TODAY(); it might make sense to unify every onWrite computation under the same structure and define ids functions like this define id sub attribute, value long, default AUTOINCREMENT(); or define id sub attribute, value string, default UUID();

=> I think this autoincrement function could be a great opportunity to open typeDB to the formula world 🤔

[flyingsilverfin]

I agree that onWrite rules are something we've been percolating for a while ;)

[lveillard]

I agree that onWrite rules are something we've been percolating for a while ;)

Btw I see 7 different ways of using those onWrite rules:

1. DEFAULT //can be overrided

• 1.1) Defining attributes (for all owners) id sub attribute, value string, default rand-uuid-v4();

• 1.2) Owning attributes (for picked onwers) person sub entity, owns id @key @default(rand-uuid-v4())

2. ON-INSERT

• 2.1) Inserts insert $newPerson isa Person, has id rand-uuid-v4();

3. COMPUTED //can't be overrided

• 3.1) Defining attributes (for all owners) id sub attribute, value string, computed rand-uuid-v4();

• 3.2) Owning attributes (for picked onwers) person sub entity, owns id @key @computed(rand-uuid-v4())

4. ON-DEPENDENCY-CHANGE (for 2025 😅)

• 4.1) Defining attributes (for all owners)

define
id sub attribute, value string, computed ?lastId 

dependencies 
$person isa Person, has id $id;
?lastId = max($id) +1;

• 4.2) Owning attributes (for picked onwers)

define 
person sub entity, owns id @key @computed(?lastId); 

dependencies 
$person isa Person, has id $id;
 ?lastId = max($id) +1;