9: Graph dependencies

Project schedules are inherently a graph: activities depend on other activities, and activities belong to projects. SurrealDB models that with RELATION tables and RELATE, not just record<> fields.

This chapter uses watch, so each schema save applies without you running another one-shot sync. Start it in a separate terminal before making any changes:

surrealkit sync --watch --user root --pass secret --ns main --db main

Leave it running while you add the files below. Stop it with Ctrl+C once you reach the checkpoint, before part 10’s rollout material.

depends_on: activity → activity

Create the file database/schema/depends_on.surql and add the following:

DEFINE TABLE depends_on SCHEMAFULL TYPE RELATION IN activity OUT activity;

This edge means "the out activity has to finish before the in activity can start".

Run this edge now in SurrealDB Studio or surreal sql, and append the same line to database/seed/demo_project.surql for the next fresh seed. Re-running surrealkit seed would replay the whole file and fail on the existing CREATE records (part 7).

RELATE activity:concrete->depends_on->activity:kickoff;

SurrealDB Studio's designer can create RELATION tables too (part 2); here we keep them in schema files for SurrealKit.

activity_of: activity → project

Create database/schema/activity_of.surql and add the following:

DEFINE TABLE activity_of SCHEMAFULL TYPE RELATION IN activity OUT project;

Same pattern: run the links now, and append them to database/seed/demo_project.surql for the next from-scratch seed.

RELATE activity:kickoff->activity_of->project:one;
RELATE activity:concrete->activity_of->project:one;

COMPUTED followed_by (backlinks)

The docs sample exposes dependents through a graph COMPUTED field:

DEFINE FIELD followed_by ON activity COMPUTED <-depends_on<-activity;

Add this line to activity.surql and save; watch should re-sync within a few seconds.

The edge was RELATE activity:concrete->depends_on->activity:kickoff, so kickoff is the dependency and concrete depends on it. Traversal <-depends_on<-activity walks inbound depends_on edges: from an activity, it finds records that point at it. Query the dependency, not the depender:

SELECT name, followed_by.{ name, progress } FROM activity:kickoff;

That returns concrete under followed_by: activities that follow after kickoff (that list kickoff as a dependency). The same field on activity:concrete is empty until something depends on concrete. This is the project-planning version of "computed backlinks" from the sketch pages: graph traversal declared right in the schema.

Graph queries

-- Dependencies leaving an activity
SELECT ->depends_on->activity.{ name, start, end } FROM activity:concrete;

-- Everything tied to a project
SELECT
    name,
    ->activity_of->project AS project,
    ->depends_on->activity AS depends_on
FROM activity;

For larger graphs, add indexes in part 12 to support range and lookup patterns.

RELATION vs record field

The docs sample uses RELATE for membership, and this course follows that.

Checkpoint

• •

  depends_on and activity_of RELATION tables in schema files

• •

  Seed data uses RELATE

• •

  COMPUTED followed_by for successor lookup (who depends on this activity)

When the graph looks right, stop watch with Ctrl+C so the terminal is free for part 10’s rollout material (then milestones in part 11).

Next: sync vs rollouts, why shared databases need a different SurrealKit command, then milestones that roll up activity progress.