I certainly hope they don't deprecate M/S, unless/until the following issues are addressed:
1) Ability to migrate without changing app ID. This is fundamental, and we've never seen any *reason* why this is impossible. I suspect that this is very hard, but not impossible. Changing the app ID causes problems because: - External references to entity keys (not IDs) are pervasive in many apps (such as google search links to deep pages, user bookmarks, or RSS feed URLs) because the documentation encourages the use of these keys in URLs - Many users have keys wrapped up in properties that the migration tool cannot recognize [this doesn't impact my app, but it's a common issue on this list] As an alternative, the infrastructure could be fixed to recognize the case of using the old app ID instead of the new app ID in a key, and quietly make the substitution. 2) Migration of large data sets takes an extremely long time. Given that we regularly see M/S downtimes in the couple of hours range, a couple of hours is probably a reasonable amount of time to migrate. A couple of days is much too much. [Note that I have not personally gotten far enough into a migration to see this duration; I'm basing this on many user complaints I've read on this list.] 3) The problem of transactional consistency needs to be addressed. It is not acceptable for transactions to end in a "maybe this worked, maybe it didn't" state. They should either succeed or fail. (Although the docs not not say whether this problem is exclusive to HR, it seems to be, and certainly it matters much more in HR since every put is implicitly transactional.) 4) As Ikai said, there are some unresolved issues in HR that need to be fixed, such as the current mystery in the 'Serious Problem: Rollback of data on HRD' thread (which is eerily familiar: I think somebody else reported a similar issue a while back). Even if all these are addressed, it would certainly be nice if M/S remained an option. It makes different trade-offs than HR, which may be better trade-offs for some applications. I will be very disappointed if they decide to make HR a requirement for multi-threading Python, since the two are completely orthogonal choices. From my reading, M/S seems to have better throughput than HR, at the expense of more frequent downtime, and spurious datastore timeouts. I'd like to have that option in a multi-threaded app. -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 google-appengine@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.
