Skip to content
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

Implications with south migration #39

Open
tsailiming opened this issue Nov 1, 2013 · 4 comments
Open

Implications with south migration #39

tsailiming opened this issue Nov 1, 2013 · 4 comments

Comments

@tsailiming
Copy link

Hi,

Do I need to restart memcache after I perform a database migration using South?

What happens to stale cache entries that may not reflect the latest changes in the model?

@jself
Copy link
Collaborator

jself commented Nov 1, 2013

Yes, it's a good idea to because columns may still be missing/etc, or any migrations that have happened won't appear in the cached version until a table write.

@tsailiming
Copy link
Author

Also, I don't think cache versioning is supported yet? This is to avoid having to start memcache from the cold state?

Any suggestions how this can be implemented together with South to achieve the desired effect? Maybe like this:

  1. By keeping an internal version column and South migration will increment it whenever the model's columns are added/removed/renamed.
  2. Johnny cache to support versioning by looking at the version column and use it for cache versioning?

@jself
Copy link
Collaborator

jself commented Nov 1, 2013

No, since we invalidate the entire table on any write (hence you essentially get a cold cache every table write), there's not much point since previous generations don't need to be kept (and roll off naturally of memcache). Versioning would just look like general invalidation. Perhaps a feature would be to invalidate all tables, or certain tables based on a migration, but the cache isn't selective enough for versioning to give much of a preformance boost.

@tsailiming
Copy link
Author

but the cache isn't selective enough for versioning to give much of a preformance boost.

Because of Johnny implementation?

My concern is that in my use case, model modifications are common but typically is limited to a few columns/tables at a time, especially when the product is not matured yet and due to the nature of CI development. Things change all the time but at a small delta each time.

Once I restart memcache, the initial loading will all be from the database even for those tables that are not changed when they are relatively static but commonly accessed such as country/city names. Though I could also warm up the cache by myself via a management command (but that will depend on the amount of cache that needs to be restored. Could be heavy on some sites that have GB of caches).

I'm guessing when the old model is deserialised and when I try to access the old/new properties, something will go wrong?

Would love to hear more opinions on how best to optimise this further.

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