Adding backlinks

This example shows how to handle a schema that makes use of a backlink. We’ll use a linked-list structure to represent a sequence of events.

We’ll start with this schema:

1. type Event {
2. required property name -> str;
3. link prev -> Event;

5. # ... more properties and links
6. }

We specify a prev link because that will make adding a new Event at the end of the chain easier, since we’ll be able to specify the payload and the chain the Event should be appended to in a single insert. Once we’ve updated the schema file we proceed with our first migration:

1. $

1. edgedb migration create

1. did you create object type 'default::Event'? [y,n,l,c,b,s,q,?]
2. > y
3. Created ./dbschema/migrations/00001.edgeql, id:
4. m1v3ahcx5f43y6mlsdmlz2agnf6msbc7rt3zstiqmezaqx4ev2qovq

1. $

1. edgedb migrate

1. Applied m1v3ahcx5f43y6mlsdmlz2agnf6msbc7rt3zstiqmezaqx4ev2qovq
2. (00001.edgeql)

We now have a way of chaining events together. We might create a few events like these:

1. db>
2. ...
3. ...
4. ...

1. select Event {
2. name,
3. prev: { name },
4. };

1. {
2. default::Event {name: 'setup', prev: {}},
3. default::Event {name: 'work', prev: default::Event {name: 'setup'}},
4. default::Event {name: 'cleanup', prev: default::Event {name: 'work'}},
5. }

It seems like having a next link would be useful, too. So we can define it as a computed link by using backlink notation:

1. type Event {
2. required property name -> str;

4. link prev -> Event;
5. link next := .<prev[is Event];
6. }

The migration is straightforward enough:

1. $

1. edgedb migration create

1. did you create link 'next' of object type 'default::Event'?
2. [y,n,l,c,b,s,q,?]
3. > y
4. Created ./dbschema/migrations/00002.edgeql, id:
5. m1qpukyvw2m4lmomoseni7vdmevk4wzgsbviojacyrqgiyqjp5sdsa

1. $

1. edgedb migrate

1. Applied m1qpukyvw2m4lmomoseni7vdmevk4wzgsbviojacyrqgiyqjp5sdsa
2. (00002.edgeql)

Trying out the new link on our existing data gives us:

1. db>
2. ...
3. ...
4. ...
5. ...

1. select Event {
2. name,
3. prev_name := .prev.name,
4. next_name := .next.name,
5. };

1. {
2. default::Event {
3. name: 'setup',
4. prev_name: {},
5. next_name: {'work'},
6. },
7. default::Event {
8. name: 'work',
9. prev_name: 'setup',
10. next_name: {'cleanup'},
11. },
12. default::Event {
13. name: 'cleanup',
14. prev_name: 'work',
15. next_name: {},
16. },
17. }

That’s not quite right. The value of next_name appears to be a set rather than a singleton. This is because the link prev is many-to-one and so next is one-to-many, making it a multi link. Let’s fix that by making the link prev a one-to-one, after all we’re interested in building event chains, not trees.

1. type Event {
2. required property name -> str;

4. link prev -> Event {
5. constraint exclusive;
6. };
7. link next := .<prev[is Event];
8. }

Since the next link is computed, the migration should not need any additional user input even though we’re reducing the link’s cardinality:

1. $

1. edgedb migration create

1. did you create constraint 'std::exclusive' of link 'prev'?
2. [y,n,l,c,b,s,q,?]
3. > y
4. Created ./dbschema/migrations/00003.edgeql, id:
5. m17or2bfywuckdqeornjmjh7c2voxgatspcewyefcd4p2vbdepimoa

1. $

1. edgedb migrate

1. Applied m17or2bfywuckdqeornjmjh7c2voxgatspcewyefcd4p2vbdepimoa
2. (00003.edgeql)

The new next computed link is now inferred as a single link and so the query results for next_name and prev_name are symmetrical:

1. db>
2. ...
3. ...
4. ...
5. ...

1. select Event {
2. name,
3. prev_name := .prev.name,
4. next_name := .next.name,
5. };

1. {
2. default::Event {name: 'setup', prev_name: {}, next_name: 'work'},
3. default::Event {name: 'work', prev_name: 'setup', next_name: 'cleanup'},
4. default::Event {name: 'cleanup', prev_name: 'work', next_name: {}},
5. }