I'm not really a developer on Django itself, but I am fairly interested in non-relational databases, and some of the things being said in this thread worry me a bit.
> 1. Nonrel DBs don't distinguish between INSERT and UPDATE > On such DBs Model.save_base() shouldn't check if an entity already > exists. Instead, it should just always INSERT. For this I added > connection.features.distinguishes_insert_from_update. That's not entirely true. Riak and CouchDB are two that come to mind instantly as explicitly distinguishing between insert and update (in Riak an update includes the vector clock information from a previous read, and in CouchDB they can be mapped to different HTTP verbs). > 2. Deleting related objects can be too costly on non-relational DBs > For this I added > connection.features.supports_deleting_related_objects. If it's False > no related objects will be deleted. Ideally, the backend should be > able to delegate this job to a background task. This is planned. Again, this seems like a GAE-specific observation. In Redis, for example, related objects can be stored in a list data structure, and the delete operation can be passed any number or keys, so it could be a very minimal set of operations to delete related objects (first read the list of related object keys, then delete them in bulk). Cassandra also has support coming for batch deletion, at which point efficient related object deletion will be similarly trivial. > 5. We need transactions which lock rows > I added a GAE-specific @commit_locked transaction decorator. This > should be moved into the backend layer, of course. I'd just like to > know if this is an option for 1.3 or not. On SQL this would be SELECT > ... FOR UPDATE, but I don't know if all SQL DBs support it. Such a > decorator would be important to make get_or_create() and a few other > functions work 100% correctly, so it would also benefit the SQL layer. > I couldn't provide the respective SQL implementations, though. This is admittedly a GAE-specific thing. I think these efforts are great--a lot of people want to get up and running on GAE with Django, and it's not so easy right now. It just worries me a bit that the description of the effort encompasses all of non-relational databases when the implementation seems to primarily reason around GAE. It makes sense to concretely pick one database and start there, otherwise no work would ever be finished, but I think that the better thing to do is to call it GAE support instead of nonrel support. Thanks, Eric Florenzano
-- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
