Skip to content

Best practice for schema migrations? #122

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kmjennison opened this issue Sep 27, 2016 · 1 comment
Open

Best practice for schema migrations? #122

kmjennison opened this issue Sep 27, 2016 · 1 comment

Comments

@kmjennison
Copy link

Adding a new field to a cached model causes an error on deployment because our code expects the new field to exist (ProgrammingError: column example_abc does not exist). Of course, the new field does not exist in previously-cached objects.

Any recommendations on how to handle schema migrations with Cache Machine?

A few ideas come to mind:

  1. Invalidate the entire cache when the schema changes. Not ideal because it's far too broad and can cause a run on the DB for high-traffic sites.
  2. Track all the queries associated with a given table and invalidate only those associated with a model. Better than clearing the whole cache, but this comes with the overhead of maintaining the flush lists of queries for a table and can still cause a run on the DB.
  3. Create middleware that invalidates individual cached queries/objects when a migration-related error occurs. E.g., on a ProgrammingError, delete any cached query and retry the query. This feels clunky because any definition of "migration-related error" will probably be imprecise.
  4. Do some cache warming. After a schema migration, instead of invalidating the cache, pull from the DB to update each cached query, and deploy when that's done. This seems like the best option, though it adds complexity and time to deployment.

Thoughts?

@tobiasmcnulty
Copy link
Member

That's a hard one.

I would add a 5th option which is to make the application aware that the objects it retrieves might be old, and do whatever is best in the application at the time (throw them away and refetch directly from the DB, for example).

Option (2) seems the most "cache machine-esque" to me and I would happily take a PR for it. I agree (4) sounds hard, and also would require making some assumptions about deployment that I'm not sure we can really make here.

(1) you can already do, of course, and I agree 4 sounds kludgy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants