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 <wkornew...@gmail.com> wrote:
> On Dec 19, 5:30 am, cz <czer...@gmail.com> 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 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
-~----------~----~----~----~------~----~------~--~---
