Schema Migration

[proven frigate]

Hi @acoustic pulsar, currently we don’t not have automated migration in our open source.

The best practice for managing schema changes is to store the schema in a central git repository and manage all changes there before deploying them through a CI pipeline that utilizes the Write Schema API. You can find more details here: https://docs.permify.co/docs/api-overview/schema/write-schema/#suggested-workflow-for-schema-changes.

We do offer some options in our cloud and on-prem offerings. If it's okay with you, we would love to learn more about your use case and understand your concerns in more detail. Feel free to book a call from our calendar: https://calendly.com/d/3nf-9q9-jpx/call-with-an-expert?month=2024-02

[acoustic pulsar]

i was more concerned about the data side
For example what happen if I rename a field of the schema ?

[proven frigate]

In our open source the renaming schema operation actually equivalent to creating new schema with new schema_id.

So let's say you want to change a relation name and write a new schema accordingly. All the data associated with that specific relation will become idle. When new access requests come to the Permify engine, this data will be ignored because no such defined relation exists in the newest schema.

You can delete this idle data by using the delete endpoint (https://docs.permify.co/docs/api-overview/data/delete-data/) or the delete bundle endpoint (https://docs.permify.co/docs/api-overview/bundle/delete-bundle/).

These operations will soft delete the data, if you want to remove them permanently you can configure garbarge collector and it will remove the soft deleted ones within the configured time period. You can find the garbage collector details in the database configuration field: https://docs.permify.co/docs/reference/configuration/