I’m working in an existing environment that has a service instance per tenant and a database schema per tenant using Hibernate.
We started to build multi-tenant (micro-)services that connect to these schemas via Hibernate. This all works well when the schema of the tenant matches with the Hibernate entity classes of the services. However, it can happen that tenant schemas are ahead or behind the Hibernate class entities of different services, for example when doing canary or staged deployments. We are looking for options to evolve our services independently from each other.
Is there anything in Hibernate or other tools/libraries that can help with evolving entity class, for example, something like if an entity field doesn’t exist in a table default to a specific value?
This is a tough topic and usually, when you “do microservices” you don’t share a database as that kind of dependency comes exactly with problems like the one you are facing now.
Regardless of the deployment model you use, this kind of problem is usually solved with database triggers and temporary defaults for columns. Usually, people do schema changes in 2 steps. The first step is backwards compatible so that both application versions can work with both schema versions. The second step is executed when you finished your roll out and won’t rollback, which will cleanup the schema, possibly remove triggers and column defaults again, since the new application version will handle this properly.
Thanks for your answer @beikov and I will explorer this option with my team. I the future we would like to build services that have their own data source and control over it and handle some data migration.
Your mentioned solution is worth a shot as an incremental approach.