Discussion Forum

Best Practices for Schema Changes?

I was wondering if there is some documentation or advice on how to manage database schema changes?

Because we are not yet in production, we are currently just dropping the db and re-initialising with a new schema each time we make a schema change. For production, we currently have the following procedure:

  1. The developer makes the schema change to a ‘master schema’, which is used to initialise a new database. The developer also creates a ‘schema change’ file with a version number, which is the next number from a version recorded in the database (in a version vertex). The schema change file contains define and undefine statements.
  2. An endpoint is called that fetches the latest schema version from the db, and then applies each schema change file.

What implications should we know about when it comes to schema changes? What are the side-effects of changing an attribute type and what is the best way to go about that? Are there any tools to help us in cases that we want to change the name of an attribute?

Interesting question!

There are some trivial things you can do like renaming types using the Concept API : http://docs.grakn.ai/docs/concept-api/type#rename-label

Add-only changes to the schema can simply be done by loading your extended schema. If you re-define anything that already exists, the change is idempotent (ie nothing happens).

Apart from that, we don’t have any particular guidelines at this point in time. Your approach of recording a sequence of steps to perform on the schema is quite interesting, and probably a good way to go. Note that if you’re undefining a type, you’ll also have to have a process to delete all instances of that type first! So the steps could be more involved.

Schema migrations in production should be relatively rare, so it’s not entirely unexpected to have a custom script or migration process each time :slight_smile:

1 Like