That aliasing via tools sounds pretty good to me. I was worried about the timing of aliasing my old app to my new one if it had to be done via raising a billing issue. Having the ability to time it ourselves is much better.
So if I understand the key conversion correctly, it sounds pretty good too. It will navigate every possible value in my data looking for and converting [encoded] keys. But just making sure - it would detect and convert both of these JDO properties: @Persistent private Set<Key> favoriteFoods; @Persistent private Set<String> favoriteFoodsEnc; //Encoded key strings, such as ag1jbGluaWNvbmV4YXBwcg8LEghQcmFjdGljZRjpBww Correct me if I'm wrong about that example. Externalized keys being used by clients is a bit of an issue for me too. I'll need to deal those old keys at the edges of the system I guess. I wish I had noticed earlier on that the app id is encoded into keys - that would have raised red flags about exposing them to clients. Actually, I should have been more suspicious about exposing a database key directly to a client no matter what its format, oops. /Tom On Jul 8, 3:17 pm, "Ikai Lan (Google)" <[email protected]> wrote: > The tool *should* preserve keys that are stored as straight keys. That is - > Keys stored in list, String or reference properties. The tool should read > these, decode them, change the app ID (so you don't get the exception about > reading data from a different app ID), and resave these to the new > datastore. > > What the tool does NOT do is smart decoding of keys. Some people do things > like sha1 the keys; this functionality will 100% break since the keys will > be different. Remember that keys encode the application ID in them. If the > application ID changes, the hashes will change. > > The tools will not allow migration within the same app ID per se. You will > need to create a new app ID. The tools will allow you to map an alias from > the old app ID to the new one, so for any routing intents and purposes, the > old app ID will still point to the new old. Internally, however, the new app > ID will be stored. This matters if you depend on any functionality that > reads the current app ID from system environment variables in production. > All new HR apps, for instance, prefix a s~ before the app ID. > > Ikai Lan > Developer Programs Engineer, Google App Engine > Blog:http://googleappengine.blogspot.com > Twitter:http://twitter.com/app_engine > Reddit:http://www.reddit.com/r/appengine > > On Thu, Jul 7, 2011 at 11:55 PM, Tom Phillips <[email protected]> wrote: > > Greg, can you reveal in advance whether the new tools will allow for > > migration within the same app id and/or preserve encoded entity keys? > > > /Tom > > > On Jul 6, 8:01 pm, "Gregory D'alesandre" <[email protected]> wrote: > > > We are working on better tools for migrating to HRD (and they are > > currently > > > being tested), I'll post once we have them widely available. > > > > Greg > > > > On Wed, Jul 6, 2011 at 5:52 PM, Waleed Abdulla <[email protected]> wrote: > > > > Please star this issue if you agree that Google should make the > > migration > > > > process easier rather than putting the burdon on the developers. After > > all, > > > > most developers signed up to GAE to avoid having to deal with issues > > like > > > > that. > > > > >http://code.google.com/p/googleappengine/issues/detail?id=5250 > > > > > On Wed, Jul 6, 2011 at 8:39 AM, Robert Kluin <[email protected] > > >wrote: > > > > >> Keys do contain the appid. > > > > >> One solution would be to adjust your code to catch the exception that > > > >> gets thrown when "accessing the old apps data", the recreate the key > > > >> for the new appid. > > > > >> Robert > > > > >> On Wednesday, July 6, 2011, Joshua Smith <[email protected]> > > > >> wrote: > > > >> > Another thing that occurs to me is that anyplace I've used a key > > > >> external to the application would have to be dealt with. For example, > > one > > > >> of our apps has an RSS feed that our managers use to keep track of > > whether > > > >> customers have uploaded new information. This looks like: > > > > >> >http://myapp.com/rss?cust=DAFHP983RPFDSALFHDSKLFJHLSDKAFH > > > > >> > (where the gobledegook is the datastore key) > > > > >> > My managers would need to update all their bookmarks, since I > > believe > > > >> that key has the name of the app pickled in it someplace, right? > > > > >> > Is there any way to avoid having the keys change when I switch to > > HR? > > > > >> > If not, is there a way that I could decorate database queries so > > that > > > >> they quietly turn old keys into new ones? > > > > >> > -Joshua > > > > >> > On Jul 5, 2011, at 3:35 PM, Joshua Smith wrote: > > > > >> >> I have several apps and I've got this pesky to-do list item for all > > of > > > >> them, to switch them over to the HR datastore. > > > > >> >> In preparation, I've read blog entries by people who have done > > this, > > > >> and I'm still on the fence about whether it is worth the trouble. > > > > >> >> I get very few datastore timeouts in my apps, and periodic > > maintenance > > > >> has never really been an issue. > > > > >> >> I've read about gotchas with eventual consistency, and it seems > > > >> unlikely that I could convince myself that I'm safe from this for any > > > >> reasonably complex app. (I'm not concerned that I cannot reprogram > > the apps > > > >> to fix the problem, but rather I'm concerned that I could not ensure > > there > > > >> weren't going to be problems. If it ain't broke...) > > > > >> >> I'm not clear on how I would go about getting google to grandfather > > my > > > >> old 2000 emails quotas if I create a new -hr version of my app. > > > > >> >> I've also read that migrating uses TONS of CPU, and it is therefore > > > >> going to cost me money to do. > > > > >> >> Really, the only reason TO do the switch is that I've read repeated > > > >> admonitions from google that I *should* be using HR. > > > > >> >> What's the consensus here? Is it worth the time, risk, and cost? > > > > >> >> -Joshua > > > > >> >> -- > > > >> >> 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. > > > > >> > -- > > > >> > 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. > > > > >> -- > > > >> ------ > > > >> Robert Kluin > > > >> Ezox Systems, LLC > > > > >> -- > > > >> 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. > > > > > -- > > > > 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. > > > -- > > 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. > > -- 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.
