In https://github.com/famedly/infra-meta/issues/2008#issuecomment-2655984434 infra asked whether they could just continuously run the migration before syncs.
This makes sense, as it would prevent missing migrations in the future, but the binary isn't currently designed for this kind of task, and will significantly increase the time syncs take, while hammering Zitadel with POST requests for data it already has, and won't show any signs of it if migration fails, instead proceeding to sync to a broken database.
We should adapt the binary to be used as a clean pre-sync, perhaps even directly integrate that into famedly-sync. We can keep a sentinel value somewhere in Zitadel metadata to denote a schema "version" while we're at it, which would significantly increase robustness in the future.
Basically, we're moving towards rolling our own database on top of the Zitadel storage model ;)
In https://github.com/famedly/infra-meta/issues/2008#issuecomment-2655984434 infra asked whether they could just continuously run the migration before syncs.
This makes sense, as it would prevent missing migrations in the future, but the binary isn't currently designed for this kind of task, and will significantly increase the time syncs take, while hammering Zitadel with
POSTrequests for data it already has, and won't show any signs of it if migration fails, instead proceeding to sync to a broken database.We should adapt the binary to be used as a clean pre-sync, perhaps even directly integrate that into
famedly-sync. We can keep a sentinel value somewhere in Zitadel metadata to denote a schema "version" while we're at it, which would significantly increase robustness in the future.Basically, we're moving towards rolling our own database on top of the Zitadel storage model ;)