We had to spend about a day after the last update because patching/ loading things we were doing to use Django 1.0 suddenly started to count against the quota.
It has been a real surprise that Django 1.0 has not been supported this long. My expectation for a beta product (app engine) is that it would be changed to support the 1.0 release of the framework quickly. They have the API versioning mechanism in place, I think it's high time to test that, otherwise it isn't really "real". On Dec 19, 7:06 am, Waldemar Kornewald <[email protected]> wrote: > On Dec 19, 5:30 am, cz <[email protected]> wrote: > > > >... complexities of getting it > > > working on your own with the current 1000 file and 1mb size > > > limitations... > > > That's the easiest part, and most appengine django users are doing > > just that (simply by omitting seldom used parts of django). The cost > > of repeated zipimports on requests is the problem. It eats into your > > quota. Unless I'm not understanding how appengine works, I would > > assume that if django 1.0 was included with the default frameworks > > there would be a high likelihood that it is always in memory. > > I'm using Django 1.0 now on appengine without any other issues besides > > that. CPU quotas are really tight right now, so it makes sense to > > minimize expensive events. That's all I'm sayin' > > The zipimport only happens on the very first request when the instance > is loaded and if I'm not totally mistaken I saw a mail from Google > stating that the first request doesn't count into your quota. So, > that's not a huge problem. > > Also, with app-engine-patch you don't need to care about zipping > Django. Just grab the sample project and get started. Our patching > method in the latest stable release is more dynamic than that of > django-helper. It only gets activated on-demand for those parts that > you actually use. For example, if you disable sessions they won't get > patched, so no CPU is wasted. Starting with app-engine-patch 1.0 we'll > provide a directly patched Django version which reduces the overhead > to pratically zero (we still patch App Engine itself e.g. to work > around bugs, but most of that will go away when they're fixed). > > The only advantage of integrating Django into App Engine is that > Google can provide a pre-compiled version. Maybe a flexible solution > would be to have a loader function which you can tell what you need: > appengine.load_package('django-1.0.2'). That would adjust sys.path and > then you automatically get the desired Django release. When there's a > new release you just change the version number in that function call > instead of manipulating app.yaml. In any case, the Django release > should be pre-patched because otherwise you need so many monkey- > patches that in the end there's not much left from the original Django > code. That's another reason why app-engine-patch switched to directly > patching Django (which finally gives us FormSets, file uploads via > ModelForm, etc.). > > Bye, > Waldemar Kornewald --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
