Seems like my message didn't reach the server. Sending again. Sorry if you receive this twice.
On 14 Feb., 03:08, Malcolm Tredinnick <[email protected]> wrote: > On Thu, 2009-02-12 at 02:14 -0800, Waldemar Kornewald wrote: > > On 12 Feb., 03:51, Malcolm Tredinnick <[email protected]> > > wrote: > > > > Is the plan somewhere on the wiki? > > > > No, because it's only something I'm pulling together slowly in my head. > > > I hope you've read my wiki page, so that in the end Django is flexible > > enough to work even with App Engine's limitations (e.g., it's > > practically impossible to implement a TransactionMiddleware): > >http://code.djangoproject.com/wiki/AppEngine > > I've had a quick read of it, but nothing serious, since I have a million > other things to do at the moment that are higher priority. However, the > overall impression from reading that is that most of those problems > aren't something Django itself will need to worry about. It's things > that the Query (and other django/db/models/sql/*) replacement will need > to handle. Yes, for most problems that's correct. Most important changes required on the Django side: * many-to-many relations need to be handled more flexibly (could be stored as an attribute on some model) * batch save/delete (at least very simple/naive implementations) must be supported (otherwise efficient websites are impossible with App Engine) > Ditto with things like replacing Permissions and ContentTypes -- that > will be up to you to fake somehow in the eventual AppEngine code. > They're part of Django, so if you choose not to use them (and I really > don't understand why you wouldn't, since they're just normal models -- > the argument seems to be that you don't want to have an equivalent of > syncdb for some reason, but that doesn't necessarily seem to be a > required constraint), you have to work around that. Regarding syncdb in general: Since you don't have shell access to the server, something like syncdb would have to be emulated with a view that is remotely accessible or using the provider's background processing facility. Unfortunately, you might hit a request limitation if you run syncdb in a single request (also applies to background processing), so syncdb should be spread across multiple requests, but it's not designed to do that and the implementation wouldn't be easy. In general, whenever syncdb isn't absolutely necessary it shouldn't be used. Regarding faked Permission/ContentType models: We could probably create all entities within a single request (up to 500 individual write operations in a single request should be doable). My point, though, is that faked models would be more efficient and much simpler (e.g., auth backend's get_group_permissions() could be reduced from 3 queries plus one client-side JOIN to 1 query without JOINs on App Engine). Also, installations/upgrades are easier if you don't need syncdb and everything magically just works. This change might not be an option for SQL, but couldn't Django at least provide a more efficient alternative for cloud backends? > > SimpleDB is even worse because of "eventual consistency" which means > > there are no transactions and absolutely no integrity guarantees. > > No, it's easier. Since there are no constraints of that nature, it's not > something we have to worry. Designing in features that are impossible > isn't a good goal to have. If you're using a storage backend that > doesn't support some kind of transactional integrity, then you simply > don't have transactional integrity. That's a constraint you accept when > choosing that storage backend. I wasn't suggesting to emulate transactions somehow, but pointing out that some backends might have very restrictive limitations and that it might be difficult to handle that in a general way. In the end, the API might look similar, but depending on the backend the semantics could be ridiculously different. That's still better than no common API, though. Bye, Waldemar Kornewald --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
