I’ve been working with this for the last couple weeks. I have been doing this for a couple reasons.
1) I wanted to play with noSQL
2) I’m developing and deploying with the google app engine — the app engine does have a mySQL option (Cloud SQL), but they have no free version of this — so to do a GAE app (entirely (including data) in GAE), you have to use the google data store or pay for SQL.
Now doing the design in a key-value noSQL wasn’t too bad. I just had a design that had each object containing the ids of the other objects that were associated with it both ways. This was somewhat redundant she thinking about it in a relational way, but it made queries simple and fast. The overhead is making sure the software keeps the ids updated in all related objects I.e. if something is deleted.
That wasn’t so bad. It was a fun to design things differently than I’m used to. Then I fleshed out the models in django.
The issue I ran into was django-nonrel. This is the project that converts django to be able to deal with non relational DBs. This changes core django abstraction models and consists of apps that can be installed locally or globally. So I installed them locally because I don’t like the idea of altering the framework globally.
It did not work with the latest version of django.
So I read through the docs a little more carefully to discover the core team quit this project over a year ago. Because noSQL wasn’t right for their projects and Cloud SQL was now available for app engine. The guy who took it over isn’t keeping it up to date with django. He’s about a year behind. It’s working with django 1.3. Current version right now is 1.5.1. That is enough to throw errors.
If django is making changes in point releases that cause the django-nonrel to become out of date, either django isn’t doing a good job at maintaining backwards compatability or (much more likely) django-nonrel project isn’t doing a good job keeping away from hacky implementations that rely on very specific django references.
I don’t have the time to debug django-nonrel. It’s like 4 apps that go in your django project.
Additionally I worked out what the cost of Cloud SQL would be for development and I can deal with less than $2 a month. When it goes production I can worry about dealing with my teams extremely poor mysql management or get my group to pay for a more substantial Cloud SQL instance.