Schema Gotchas

Graphweaver aims to be un-opinionated about how you model your data, but we’re not fully there yet. Some things are not yet supported, but PRs are always welcome!

• Composite Keys
• Foreign Keys to Non-Primary Keys

Composite Keys

Graphweaver does not yet support composite keys. A composite key is when you need to use multiple columns to uniquely identify any specific row in the data source.

We would be happy to support these, it’s just not something we’ve implemented yet. One possible workaround is to create a GENERATED ALWAYS AS column that composites the keys for you automatically, or create a separate automatically generated identity column for the primary key then reference this in your other entity foreign keys. This approach works in many cases.

Foreign Keys to Non-Primary Keys

Let’s say you have the following in your database:

CREATE TABLE "Pet" (
    id INT PRIMARY KEY,
    name text NOT NULL,
    -- ...etc, additional columns
);

CREATE UNIQUE INDEX pet_name ON "Pet"(name text_ops);

CREATE TABLE "Appointment" (
    id INT PRIMARY KEY,
    petName text NOT NULL REFERENCES "Pet"(name)
);

In this case the petName column is a foreign key. It’s been modelled with the name as the joining column. The name is guaranteed to be unique given the unique index, so this is perfectly valid from a database design perspective, but currently Graphweaver does not support this arrangement, as we expect the primary key to be what’s referenced in the relationship.

This setup is usually to make it easier to manage the data by hand as it’s more readable when looking at the database directly. If you are ready to embrace Graphweaver’s approach, you can update your schema so the foreign key references the primary key on each entity like so:

CREATE TABLE "Appointment" (
    -- ...etc
    petId INT NOT NULL REFERENCES "Pet"(id)
);

This way the relationship is supported. The admin area will display relationships as a dropdown when creating / editing, and you can set the name column as the adminUiOptions.summaryField for Pet , which will mean that when a Pet is referenced in your other entities the name will be displayed instead of the id in the admin area. In your queries you can do this to get the name:

query {
  appointments {
    id
    pet {
      name
    }
  }
}

It still will not make working directly in a database viewer easier, but it’s pretty close! Equally this is a feature we could support, so if you would like us to work on removing this limitation, let us know.