You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ;)
The text was updated successfully, but these errors were encountered:
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 ;)
The text was updated successfully, but these errors were encountered: