Advent of TypeQL: Day 1
Happy Advent!
Welcome to our Advent of TypeQL. Each day, we’ll post a small series of TypeQL challenges. There will be 14 days from December 11 to December 24, inclusive, so stay tuned!
It’ll be easiest to work through the days consecutively, since they are designed to incrementally build up an intuition of TypeQL. However, each day will also have a shortcut setup to just get a database for that day’s activity, allowing you to hop in without going through all the previous days challenges if you want.
You’ll want to use TypeDB Studio or TypeDB Console running against a TypeDB Cloud or local instance of TypeDB CE.
Background
Santa was preparing to release his Christmas plans. Finally done, he had just torn down his development and staging environments in preparation for a production launch of his grand Christmas plans…
Unfortunately at that precise moment, all of his Christmas plans, supposedly safely stashed in his git repository, got deleted by a pesky engineer with an overly permissive Github token and a mistyped command. Oh dear!
Santa contacted support and was able to recover some of his plans. However, they are incomplete. We’re going to help Santa get his plans back on track for Christmas, one day at a time!
Setup
You can load Santa’s recovered database schema by copying the linked schema text into a schema transaction’s query interface in Studio or Console, and the commit (note: by default, Studio auto-commits each query when set to “auto” mode).
Get the recovered data loaded by doing the same (follow link, copy text, paste into Studio or Console), but this time use a write transaction – then commit.
At this point, you should have a database with an older version of Santa’s plans!
Day 1
Let’s spend today getting to know Santa’s plans. TypeDB databases contain both schema and data. Before we explore whatever his data is, let’s see what’s in his schema.
TypeDB schemas contain types and their connections, and describe the architecture of your data – kind of like classes, or blueprints or DNA! Data is created by instantiating those types – like in object oriented programming!
TypeDB schemas are readable through TypeQL, same as data. Let’s poke around using match queries! If you’re using TypeDB Studio, I recommend looking at the outputs in `table` view.
Exploring the schema
Let’s start by writing a query listing all the entity types in the database.
Answer
match entity $t;
That’s interesting, Santa’s got a representation of his Elves! I wonder what kind of data can be attached to them?
In TypeDB, data values are only carried in attributes, which are independent data points instantiated from attribute types, then attached to owners (either entities or relations).
The ability to own attributes must have been granted in the schema, so we can inspect exactly what an Elf’s possible attributes can be by looking at the elf entity type’s owned attribute types!
So: what attribute types can an elf have? Let’s query the schema owns definitions to answer that.
Answer
match entity $t, label elf, owns $a;
Alternatively, use shortform:
match elf owns $a;
Next: entities can be connected to other entities via relations, so let’s list the relation and play-ed role types connected to elf.
Answer
match entity $t, label elf, plays $role;
Alternatively, use shortform
match elf plays $role;
This is somewhat interesting, we can see the elf can be being in a lives-in relation, and a builder in a production relation! Let’s look up what other roles exist in the second relation type…
Answer
match relation $r, label production, relates $role;
Alternatively:
match production relates $role;
So, a production, relates a blueprint role and a builder role. One last thing: let’s look up all types that can play each role in production, combining the two previous ideas!
Answer
match relation $r, label production, relates $role; $t plays $role;
Alternative:
match production relates $role; $t plays $role;
Exploring the data
Now we know that there are blueprints for presents, elves, and production relations between elves and presents! Let’s check if there is any data for these types.
Let’s look up all elf data instances!
Answer
match $elf isa elf;
It’s not very interesting, since each elf only has its instance ID when queried like this! Let’s match also the elf’s name, status, and email.
Answer
match $elf isa elf, has name $name, has email $email, has status $status;
Looks like we have some retired and some working elves with spice-y names!
If we wanted to format output as JSON instead of rows, we can use the fetch clause. The $var.* is a handy shorthand to get all attributes of an entity or relation when we start using fetch! Let’s fetch each working elf’s attributes using the fetch clause.
Answer
match $elf isa elf, has status "working";
fetch { $elf.* };
Ok, last one: remember that any elf can participate in a lives-in relation. lives-in has another role: location. Let’s get each working elf’s location, and fetch those location’s attributes!
Answer
match
$elf isa elf, has status "working";
$lives isa lives-in, links (being: $elf, location: $location);
fetch { $location.* };
Alternatively, using syntactic sugar to shorten the query:
match
$elf isa elf, has status "working";
# Type inference will work out relevant role type for $elf:
lives-in ($elf, location: $location);
fetch { $location.* };
It seems like Santa has approximately one elf working on each continent… he’s hired supersonic workers to produce all his presents! We’ll work out later how many presents of each type each working elf is meant to produce!
See you soon!
Thanks for helping clean up Santa’s data disaster! We’ll see you tomorrow for Day 2!
If you encounter any issues, want to chat, or anything else – feel free to post in our Discord or feel free to email me directly.