Why Data Migrations?
Coming from a relational database world and spending a big chunk of my career working with Rails and Phoenix apps, I’ve become used to some of the standard tooling around change management in the database.
Now that I work with Fluree as the backend, many things are different, but the desire to see how the schema evolves remains.
Getting schema changes stored in the codebase streamlines them into the code review process. It allows build servers to build the correct version of the schema and dev versions to stay in sync with the correct version corresponding to the checked-out code branch.
How About in Fluree?
Fortunately, there are some ways to manage this working with Fluree. For one, since schema is data, you can transact the whole schema at once to upsert the predicate additions and changes. You can then store a schema.json file in your codebase/source control and track changes over time.
Even Better with VSCode
If you are working with VSCode, it gets even better. My colleague, Andrew Johnson, recently updated our Fluree VSCode extension with the functionality to pull the schema changes right from your ledger. It stores them in a migrations folder in your codebase as JSON formatted transactions from the block where the changes were made. The Fluree VSCode extension also makes it easy to run transactions for a JSON file or even from highlighted text.
One of the core philosophies of Fluree is data centricity – the idea that data can and should power multiple apps without massive overhead of APIs, ETL jobs, and other integration middleware. Another nice thing about the VSCode extension is that it allows multiple apps to work with the same ledger since all changes are being pulled/stored in the ledger, making it the source of truth.
Managing changes to your schema is an important job of any team creating software. With Fluree, the database can remain the source of truth while still providing you with the information you need to review and understand these changes over time.