On Thursday, April 8, 2010, flo...@gmail.com <flo...@gmail.com> wrote: > On Apr 8, 10:50 am, Javier Guerra Giraldez <jav...@guerrag.com> wrote: > >> A: use the _same_ ORM with NoSQL backends. then it's important to >> provide (almos) every capability of the current ORM, even if they have >> to be emulated when the backend doesn't provide it natively. > > To do this would mean to essentially implement a relational database > on top of a non-relational data store. Except it would be worse, > because instead of using the database's built-in logic, you'd be doing > all of these operations over the network. It would also be very, very > difficult to do this in a way where the abstraction wouldn't break > down when doing anything non-trivial.
What I'm proposing is not a complete emulation of all features at all cost, but simply an automation of the things that are possible and in wide use on nonrel DBs. Moreover, you'd only use these features where actually needed, so this would be a helper that replaces exactly the code you'd otherwise write by hand - nothing more. Denormalization, counters, etc. indeed go over the network, but people still do it because there is no alternative (CouchDB being an exception, but there we can auto-generate a view, so the index is created on the DB: same game, different location). I'm also not saying that this should be tightly integrated in Django. It's good enough to provide a separate package that adds these features. I'm just concerned that Alex' refactoring will make it more difficult or even impossible to implement an emulation layer because his goal is totally different. 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 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.
