Plus you'll need to sync those data until v2 is live. On Sep 23, 5:22 am, Tim Hoffman <zutes...@gmail.com> wrote: > Yep you will duplicate your data,. > > I don't think its a good idea unless you only have a very small amount > of data. > > T > > On Sep 23, 9:39 am, Kyle Baley <k...@baley.org> wrote: > > > > > That's an interesting idea. But if you do that, wouldn't you need to > > first copy all the data from the v1 namespace to the v2 namespace? > > > On Sep 22, 7:07 pm, Eli Jones <eli.jo...@gmail.com> wrote: > > > > It might be useful for you to use a namespace for the new version of the > > > datastore. > > > > Thus, you could have the "new version" of the app deployed as a non-live > > > version of the app.. and code that "new version" to use the "new version > > > datastore" namespace. > > > > Then, when you are ready.. just change the live version of your app to the > > > "new version". > > > > Here's a link: > > > >http://code.google.com/appengine/docs/python/multitenancy/multitenanc... > > > > <http://code.google.com/appengine/docs/python/multitenancy/multitenanc...>So.. > > > you could just think of your version 1 datastore as "that old customer who > > > we're going to dump just as soon as our new version 2 datastore customer > > > is > > > ready"... or something like that. > > > > It's better (I think) than adding a "version" property to all of your > > > models > > > or trying to maintain model consistency between app versions. > > > > On Mon, Sep 20, 2010 at 2:29 PM, Kyle Baley <k...@baley.org> 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 google-appeng...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > google-appengine+unsubscr...@googlegroups.com<google-appengine%2Bunsubscrib > > > > e...@googlegroups.com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/google-appengine?hl=en.
-- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
