I'm considering the samme issue currently, and I'm looking forward to see other suggestions. Here mine.
Up until now i have gotten away with making entities backward compatible. They have so designed them so they can be upgraded on the fly and stille work even though not upgraded. But this i probably coming to and en since some changes can just not be made that way. I'm very much against option 1. IT's hard to test the upgrade, and if something goes wrong during the update you have no transactional logic to protect you. The only way too rollback would by making a data dump and restore that if things go wrong. More time spent, more things which needs to be tested. That leaves option 2. This has the the advantage that you can start the upgrade before changing default versions and you don't have any downtime. The entities still need to be somewhat backward compatible since you probably want to upgrade before changing the default version. Also it's easier to "recover" from since you can probably live with some entities needing som patching for a while if something goes wrong - your system will run as a whole. I'm not sure how well a version number will do in the indexes. And off course there is the waste of an entire index, just for recording metadata about the entity As mentioned, I hope we see some other update strategies in the thread. Cheers Tonny On Sep 20, 8:29 pm, Kyle Baley <[email protected]> wrote: > We've just released the first version of our application and are now > looking at a problem we've been avoiding until now. Namely, what is > the best way to upgrade the application to a new version that requires > changes to the datastore. We're looking at two options: > > 1) Big Bang Upgrade > We take the application down and run an upgrade process to update all > entities from version 1 to version 2. > > Pros: Easy to maintain; intuitive > Cons: App has to be taken down for a period of time, which will > increase as time passes and more data is added to the datastore > (potentially hitting the limit for long-running processes eventually) > Question: What's a good way to take the app offline? > > 2) Version Entities Individually > Each entity has a version number and we have a series of commands, > each one responsible for upgrading an entity from one version to the > next. As we request entities, we check to see if it's the latest > version. If not, we run each necessary upgrade command in sequence > until it is the latest version. > > Pros: No need to take the app offline; provides flexibility on whether > to upgrade everything at once or piecemeal > Cons: Not as intuitive; entities with different versions in the > datastore (if that matters) > > What do other people do to upgrade their datastore for a live > application? -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
