Djangae lets you use the Django ORM with the Datastore, meaning you don't have to use NDB. It also has lots of other helpers for things like deferred tasks.
The Django NDB middleware written by Google, as far as I can work out, just makes sure that writes are flushed. You still have to define and query your models using NDB syntax.
CloudSQL works great for django, I suppose that these attempts to port django to cloudstore are looking for the free tier that is provided. In theory you could host an app for free if it's small and uses the datastore. While with cloudSQL you'd have to spend some money
There are many benefits, depending on your situation. If your website is expected to get a high QPS, or you have a lot of data (e.g. millions of rows) then using the datastore can be much more suitable (you don't have to deal with schema migrations or connection limits etc.)
You, of course, have to put much more thought into the model design on the datastore and your design should play to the strengths of a non-relational store but once you have that right your site will seamlessly scale.
But CloudSQL is also more suitable in many situations, there are no aggregates or joins on the datastore. You need to to pick and choose the right technology for what you are doing.
Djangae is awesome here, because you use a consistent API for both CloudSQL and the Datastore, which makes switching between the two much easier.
This has actually been done many years ago. http://django-nonrel.org . Don't know how it differs from this one, but it has many of the same features. Used it for a project 4 years ago.
Yeah, we used Django-nonrel and Djangoappengine for a long time, and Djangae is heavily inspired by it. However the advantage that Djangae has is that it works with normal Django - it doesn't require a patched fork like djangoappengine.
As for performance, it depends what you are doing. Obviously the datastore is non-relational so it scales much better with a lot of data, and you don't have to deal with things like migrations or connection limits. But then you can't do complex queries and aggregates etc. the good thing about using Djangae is you can make use of Django's multiple database connections to store your data in whichever form makes sense (datastore or CloudSQL).
As Django developer for over 6 years, sorry guys I don't see the benefits of hacking the framework in this case. I know so many people love django out there and try to apply it as much as they can. When you think you go with the-easy-thing, you're going to make it harder.
BTW, depending on the purpose, I will go with another frameworks, even another languages.
What django version is this based on? Some of the other nonrel projects that I'm aware of are based on the LTS 1.4 (LTS until next year), and haven't really progressed from there.
1.6 is supported in the alpha, we're aiming for 1.7 support before beta. From that point on we intend to support the two most recent stable Django releases.
We structured the Djangae database connector to be as de-coupled from Django as possible (everything happens at the cursor level) so hopefully keeping up with Django releases should be fairly easy (hopefully!).
There is not much love in the Django community towards web2py (to put it lightly), but if you are interested in Django on GAE it might be interesting to give web2py (for which GAE is a native backend) a look.
The main complaints against web2py are that it is "un pythonic" because it automatically imports some things for you (from Jacob Moss Kaplan / django), and that it re-executes scripts leading to some unavoidable memory leaks in some (arguably, non-idiomatic, easy to avoid and extremely rare) situations (from Armin Ronacher / flask). I hope I have properly summarized and not misrepresented the core arguments - apologies in advance if I did.
Having used both django and web2py for commercial uses, and helping newbies on the web2py list, I would say that these complaints have no practical significance. In my opinion, web2py is simpler and easier to use; and if you need GAE support, it's there.
17 comments
[ 2.4 ms ] story [ 53.3 ms ] threadIt does reduce the barrier to use Django in AppEngine and does remove the need for the cloudsql db instance(mysql)
https://cloud.google.com/appengine/docs/python/ndb/#integrat...
The Django NDB middleware written by Google, as far as I can work out, just makes sure that writes are flushed. You still have to define and query your models using NDB syntax.
You, of course, have to put much more thought into the model design on the datastore and your design should play to the strengths of a non-relational store but once you have that right your site will seamlessly scale.
But CloudSQL is also more suitable in many situations, there are no aggregates or joins on the datastore. You need to to pick and choose the right technology for what you are doing.
Djangae is awesome here, because you use a consistent API for both CloudSQL and the Datastore, which makes switching between the two much easier.
How is performance compared to using cloud sql ?
As for performance, it depends what you are doing. Obviously the datastore is non-relational so it scales much better with a lot of data, and you don't have to deal with things like migrations or connection limits. But then you can't do complex queries and aggregates etc. the good thing about using Djangae is you can make use of Django's multiple database connections to store your data in whichever form makes sense (datastore or CloudSQL).
BTW, depending on the purpose, I will go with another frameworks, even another languages.
We structured the Djangae database connector to be as de-coupled from Django as possible (everything happens at the cursor level) so hopefully keeping up with Django releases should be fairly easy (hopefully!).
The main complaints against web2py are that it is "un pythonic" because it automatically imports some things for you (from Jacob Moss Kaplan / django), and that it re-executes scripts leading to some unavoidable memory leaks in some (arguably, non-idiomatic, easy to avoid and extremely rare) situations (from Armin Ronacher / flask). I hope I have properly summarized and not misrepresented the core arguments - apologies in advance if I did.
Having used both django and web2py for commercial uses, and helping newbies on the web2py list, I would say that these complaints have no practical significance. In my opinion, web2py is simpler and easier to use; and if you need GAE support, it's there.