I have no issues with data store or memcache partitioning/versioning. I know how to evolve the schema, how to deal with serialization changes, applying version numbering schemes if needed, etc...
My problem is specific to cron jobs: GAE does not dispatch the cron invocation to it's proper place. If your active "production" version simply does not have the implementation yet, your cron job scheduled in the "test" version will still be active, but yielding a bunch of errors - instead of calling the implementation in "test". Regards, Viktor On Feb 3, 1:17 pm, John Patterson <[email protected]> wrote: > Cron jobs always execute against the default version. > > A feature I use a lot to compartmentalise data with Twig is "versioned > datastores". It basically just prepends a version number to the > Entity kind for all instances stored or queried with that session. So > effectively you have multiple separate name spaces in a single > datastore. This is very handy for upgrading your data schema or > starting fresh with a new data version when I update my entire > database. Its undocumented at the moment but if you want more details > let me know. > > http://code.google.com/p/twig-persist/ > > On 3 Feb 2010, at 17:57, Kasper Hansen wrote: > > > > > Hi, > > > It's the same with data. Data is for all versions. I don't want to say > > this is a bug, because in some regards it's nice that data is shared, > > but in other situations it's not. It would be nice to be able to > > "compartmentalize" an app somehow. > > > :-) Kasper > > > On Wed, Feb 3, 2010 at 11:40 AM, phraktle <[email protected]> wrote: > >> Hi, > > >> There appears to be a bug - or at least undesired behavior - > >> regarding > >> cron jobs. Let's say there's a "test" and a "production" (the active) > >> version of an app. If you add a cron job to cron.xml in "test", one > >> would expect that job is bound to that specific version. Instead what > >> I'm seeing: > > >> - the cron job is listed in the GAE administrator for both apps (ie. > >> regardless of what you select in the app version dropdown) > > >> - the cron gets invoked on "production" - and fails, as that version > >> doesn't have the implementation > > >> For me, this is clearly a problem. The documentation does not specify > >> how versions relate to cron jobs... however, the docs imply it's okay > >> to run several distinct versions, even with different runtimes (ie. > >> mixing java and python). Based on this the only reasonable approach > >> would be to bind the cron job to the specific version of the app. One > >> also needs this separation to be able to test the cron job's > >> operation > >> before going live. > > >> If running the cron job in the "test" version is not desired (eg. if > >> the same job is already active in production), the developer should > >> simply disable it in that version (either in cron.xml, or by detect > >> the current version in the job implementation). > > >> Regards, > >> Viktor > > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Google App Engine for Java" 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 > >> athttp://groups.google.com/group/google-appengine-java?hl=en > >> . > > > -- > > You received this message because you are subscribed to the Google > > Groups "Google App Engine for Java" 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 > > athttp://groups.google.com/group/google-appengine-java?hl=en > > . -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
