Pregunta

We have what can be called a distributed application: One full-blown web app and a small REST service. Both must be separately deployable. Both access the same database schema (they actually share only two tables). The common functionality is encapsulated in a common artifact (a JAR file here, since it’s all Java). So far, so good.

However, I’m unsure how to handle schema changes properly. The web app uses Flyway for its schema updates, it works like a charm. But what should be the recommended procedure if one of the shared tables needs an update? Whose responsibility should the upgrade be? (At the moment it is the web app that performs all the upgrades, perhaps that’s good enough, but it worries me.)

I thought of perhaps even changing the architecture to have a separate application or service that has both web app and REST service as a client, but this would only make things difficult, not actually remove the problem.

¿Fue útil?

Solución

The way Flyway describes itself, it scans both the existing status of the database schema and all defined "migrations" on the class path of the program it is used in, and then automatically does the right thing. Therefore, the obvious answer is "both". Whoever happens to access the database first will perform the migration, so the other client won't have to.

(Obviously there is a possibility that both clients might access the database in an overlapping way and "steal" each other's upgrades. But this is no different from managing any normal read-write access to a shared resource - if you need transactional semantics, I assume that you already have a way of ensuring it.)

Otros consejos

Your webapp directly accesses the DB? That's a bit of an anti-pattern right there and shouldn't be encouraged (for security reasons mainly), so I would try to put the DB with the another app-tier service as much as possible partly to try to encourage splitting DB access from client (or web server) access.

Otherwise, just create a new component that is "the DB" and it handles all schema changes independently of both - then neither is going to mess up the others schema changes, and both will have to get used to using this new project as a dependancy.

Licenciado bajo: CC-BY-SA con atribución
scroll top