Google App Engine & Django
Ramin Firoozye
http://code.google.com/appengine/
Apparently, you can run the entire Django stack with a few
modifications on top of Google's infrastructure
(http://code.google.com/appengine/articles/django.html) and for most
basic apps, it's free.
Caveat: there's a waiting list for signing up.
Ramin
Marty Alchin
> Caveat: there's a waiting list for signing up.
Another caveat, according to that same page you linked:
"Since App Engine does not support Django models, leave all DATABASE_*
settings set to an empty string. The authentication and admin
middleware and apps should be disabled since they require Django
models. The functionality these provide is covered by the App Engine
Users API and Admin Console respectively. Sessions also depend on
Django models and must be disabled as well."
Without models, the vast majority of Django apps won't run at all.
-Gul
Marc Garcia
appengine models. Anyway, I think that there is an important day for
django. I haven't enought time to check it all, but I think in a close
future we'll be able to run our django 1.0 projects on google
infrastructure.
For know I think that it's too early to migrate, because probably
isn't a very mature project, and specially because it's working on
django 0.96 (and most django users use trunk or sometimes newforms-
admin, like me).
Marc
Marty Alchin
> Well, it seems that you just need to migrate your django models to
> appengine models.
The trouble is who "you" are. I make use of a number of third-party
apps, and I don't much enjoy the idea of having to migrate *their*
models over to appengine, only to have to keep those changes in sync
with other updates to the apps.
Maybe after queryset-refactor lands, we can get a BigTable backend to
actually run all existing apps, including the built-in auth and admin
apps. A pipe dream, I expect, but that's my hope, anyway.
-Gul
Mat
support into the ORM, shouldn't all other modules work after the model
system is updated?
Mat
Marty Alchin
> Why don't we start a new branch (probably off query-set) to include bigtable
> support into the ORM, shouldn't all other modules work after the model
> system is updated?
They should, although it shouldn't need a whole new branch, I don't
think. Once qs-rf lands, it should provide enough hooks that a
database backend should suffice. It still won't be simple, but it
shouldn't need a branch of Django's own code.
And since appengine lets you drop in your own Django codebase, we
should be able to just use queryset-refactor already, even if we don't
wait for it to be merged to trunk. I just don't know enough about it
to venture into that myself yet.
-Gul
Mat
catch I can see is bigtable doesn't support joins (as I understand it), so
that could be a limitation, but I guess multiple db requests isn't beyond
reason.
You can certainly run your own django version on appengine, but without db
support its limited, even sqlite wont work, as we don't have filewrite
access :(, needs a new db backend adding into django as far as I can tell.
Mat
-----Original Message-----
From: django...@googlegroups.com [mailto:django...@googlegroups.com]
On Behalf Of Marty Alchin
Sent: 08 April 2008 14:01
To: django...@googlegroups.com
Subject: Re: Google App Engine & Django
Sam Willis
to integrate django ORM with it. Could be a fun little project though.
You would have to manually do the joins by doing multiple bigtable
requests. If I have some free time over the summer I tempted to have a
bash at it but it will require a lot of work and wont be very
efficient. It might be an idea to just add basic support without joins
so that things like the admin interface and auth work and then build
up from there.
Sam
On Apr 8, 1:40 pm, "Mat" <dja...@wakari.co.uk> wrote:
> Why don't we start a new branch (probably off query-set) to include bigtable
> support into the ORM, shouldn't all other modules work after the model
> system is updated?
>
> Mat
>
> -----Original Message-----
> From: django...@googlegroups.com [mailto:django...@googlegroups.com]
>
> On Behalf Of Marty Alchin
> Sent: 08 April 2008 13:33
> To: django...@googlegroups.com
> Subject: Re: Google App Engine & Django
>
Mat
Would it not be possible to simulate joins in the ORM by doing multiple
requests? Like I said I don't know the backend code, so this could be either
trivial or impossible and I wouldn't know the difference!!
David Larlet
Le 8 avr. 08 à 14:16, Marc Garcia a écrit :
>
> For know I think that it's too early to migrate, because probably
> isn't a very mature project, and specially because it's working on
> django 0.96 (and most django users use trunk or sometimes newforms-
> admin, like me).
You can use your own version of Django, see http://code.google.com/appengine/articles/django.html
David
Mike Axiak
insight into the DataStore <--> Django Models mapping problem.
Hopefully it won't get lost amid the influx of emails on that list.
Cheers,
Mike
1: http://groups.google.com/group/google-appengine/browse_thread/thread/7f26edc0ec716551#
ydjango
like mysql and postgressSQl, Google Apps Engine usefulness appears to
be limited to more Content Management kind of web application.
It pretty much excludes data driven and data intensive applications
where data consistency and reliability is very critical (ACID
properties).
Unless I am missing something and Google Data store is intended to be
full Object Oriented DB equivalent of Relational DBMS's.
Still it is an exciting development and another great option to
Amazon s3/ec3 services.
thanks
Ashish Gupta
Eduardo O. Padoan
>
> I agree, with no support for Django Models and relational databases
> like mysql and postgressSQl, Google Apps Engine usefulness appears to
> be limited to more Content Management kind of web application.
> It pretty much excludes data driven and data intensive applications
> where data consistency and reliability is very critical (ACID
> properties).
>
> Unless I am missing something and Google Data store is intended to be
> full Object Oriented DB equivalent of Relational DBMS's.
Jut because it is not relational, does not mean that it have no ACID properties.
> Still it is an exciting development and another great option to
> Amazon s3/ec3 services.
>
> thanks
> Ashish Gupta
>
>
> On Apr 8, 4:31 am, "Marty Alchin" <gulop...@gamemusic.org> wrote:
>
>
> > On Tue, Apr 8, 2008 at 2:28 AM, Ramin Firoozye <ram...@gmail.com> wrote:
> > > Caveat: there's a waiting list for signing up.
> >
> > Another caveat, according to that same page you linked:
> >
> > "Since App Engine does not support Django models, leave all DATABASE_*
> > settings set to an empty string. The authentication and admin
> > middleware and apps should be disabled since they require Django
> > models. The functionality these provide is covered by the App Engine
> > Users API and Admin Console respectively. Sessions also depend on
> > Django models and must be disabled as well."
> >
> > Without models, the vast majority of Django apps won't run at all.
> >
> > -Gul
>
> >
>
--
Eduardo de Oliveira Padoan
http://www.advogato.org/person/eopadoan/
Bookmarks: http://del.icio.us/edcrypt
James Bennett
> It pretty much excludes data driven and data intensive applications
> where data consistency and reliability is very critical (ACID
> properties).
Yeah, Google certainly use their platform to do any data-driven or
data-intensive applications, after all...
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
ydjango
But If I consider moving to Bigtable in future, I need some visibility
into
1) Is BIGTABLE fully acid complaint? from what I have read it is not
atleast in some cases.
2) in what cases is it not acid complaint? Moving from RDMBS world
what should I watch out for or compensate for? services which I take
for granted in good RDMBS like Oracle, but are missing here.
3) Should I even move from RDBMS to it? Is it even a good subsititute
for RDBMS for transaction processing systems? It seems it is good for
Data warehousing, Historical data, data mining etc.
4) How do we do backups?
It is new paradigm from RDBMS and requires some new thinking from my
side as well.
thanks
Ashish
On Apr 8, 10:43 am, "Eduardo O. Padoan" <eduardo.pad...@gmail.com>
wrote:
brox
http://blog.broxrost.com/index.php/2008/04/08/django-on-google-app-engine/
I agree with the other posters that the model API seems a bit lacking.
Without having studied it too closely, it seems that using GQL in
model queries is the norm rather than the exception.
--Thomas
Rock
Brox ... Nice writeup! Many thanks!
Now for my thoughts...
I have been using PyTables as an adjunct datastore along with
the Django ORM for almost a year. To me, BigTable looks a lot
like PyTables and, as such, I know that it can be be a great
supplement to the Django ORM in certain scenarios. GQL may or
may not be a great idea, but I certainly don't think that it
is a bad idea as I have had similar thoughts when contemplating
improving the integration of PyTables and Django.
The key to me is multiple database support. Then we can keep
the ORM and also develop a OTM (ObjectTableMapper) perhaps
targeting GQL and take advantage of both datastorage models.
Plug in a GQL front-end to PyTables and much of the anguish
of being tied to the GoogleAppEngine starts to disapate.
I guess I will have to review the work that has been going on
for multiple DB support and see if it needs to be extended to
also include support for multiple model mappers.
Chris Hoeppner
I see the similarities between them and django models, tho Django knows
where to look for them, and thus knows how to manage those classes.
Appengine has it's own stuff, and at the bottom of the django page it's
said that you don't need to run manage.py to setup the models. How does
this work then? Am I to write the models (in appengine-slang) and just
place them were I used to place django models? It really makes no
difference beside the import phrase if you place them elsewhere,
assumedly, but perhaps AE is just looking elsewhere or uses some
discovery system we should be aware of? I haven't (yet! still browsing)
seen any reference to this.
Okay, anything built on django models won't work. I don't care. I don't
use the admin interface but in the *very* early stages, as scaffolding,
and then build my own admin usually. And if AE provides consistent user
auth, there I have all I need to get building on AE and scrap hosting
headaches from my todo list.
I recon, it's early. Beta. Probably oob (out of beta) very soon (tm).
Like a couple years. But I'm in to start and get the hang of it. If
everything rolls, it's on to get The Standard Django Hoster for ages.
And even if it's non-free, if it once-and-forever takes the hassle of
setting up some hosting for django out of my life, I'll pay them in gold
bars!
I will continue traversing the docs and share anything I discover (tho
I'm sure not the first one, even from us on the list). And if you happen
to get one of those you-gotta-wait accounts, and have the valour to try
and get django up and running, please share the joy.
~ Chris