On Sun, Jun 24, 2012 at 10:31 PM, Adam "Cezar" Jenkins <emperorce...@gmail.com> wrote: > I'm only lightly involved in the project, but there is some misinformation > going around about it. > > On Sun, Jun 24, 2012 at 5:47 AM, Daniel Greenfeld <pyda...@gmail.com> wrote: >> >> >> >> We evaluated django-nonrel for use in projects and looked again at >> django-nonrel for our talk at DjangoCon Europe. To summarize our >> findings and opinions: >> >> 1. django-nonrel is stuck on Django 1.3, which has some security >> implications. > > > 1.4 support is implemented and being tested in a beta mode right now. > >> >> 2. django-nonrel is unsupported. It switched maintainers and the >> current maintainer is not working on it. > > > Django-nonrel is very much maintained. Look at the > github https://github.com/django-nonrel/ > >> >> 3. [pydanny opinion warning] django-nonrel wasn't adopted in Django >> core because it lacked adequate documentation and tests. > > > This is true.
It's not the only reason that django-nonrel wasn't adopted. Another big reason is that django-nonrel made/makes a number of major structural changes to the internals of Django's ORM. Some of these changes would be backwards incompatible, and some are major changes that haven't been adequately explained. For example, the last time I looked at the problem, there was *at least* one *major* problem that appeared to require a backwards incompatible change in order to work. Specifically, Django currently makes the assumption that AutoFields are integers, and on many non-relational stores (IIRC MongoDB is one on this list), the automatically allocated key is a UUID. This poses a problem because Django needs to have a way to work out which key to use, and despite the efforts of django-nonrel and Alex Gaynor's GSoC project, I don't believe an elegant solution has been proposed. >> 4. [pydanny opinion warning] django-nonrel treats MongoDB as a >> relational store, which it most certainly is not. > > > The idea is to use the same ORM as you would any other DB, so yes the ORM > does make some assumptions. Though you get Dict/ListFields, Embedded Models, > etc. Many of these are available on good relational stores, anyway (PostgreSQL has plenty of exotic column types). The issue is more about the fact that relational stores assume that joins are relatively cheap; non-relational stores (broadly speaking) don't. As a result, the way you frame your problem will be different. A third normal form deconstruction of a data space works really well with a relational database, but will not perform well if you try to implement it on a non-relational store. There are things that relational stores do well, and there are things that non-relational stores do well; trying to make a non-relational store behave like a relational store means you're going to get the advantages of neither. >> 5. [pydanny opinion warning] django-nonrel smells like a giant hack >> done by very well intentioned people.. > > > I have to agree with you here. The nature of the Django ORM makes anything > like this a hack. Not much choice in that regard. > > I've wondered if it's possible to make an ORM that API compatible with > forms/admin/etc that doesn't hack onto the existing ORM? There's an extent to which "Does Django support non-rel" is really just asking "Can I use the admin and Django Forms with non-rel"; so rather than trying to plug a non-relational store in as an ORM backend, it may be better to find a higher level point of API compatibility. However, I'm not sure there would be that much difference between a "Mongo ORM Backend" and a "Django ORM API compatible replacement". The ORM is already split into a frontend/backend API. The frontend is all the public facing filter/exclude type calls, which any ORM-replacement would need to emulate, so if you were to write something that was API compatible, you're just going to end up duplicating a lot of front-end code. That said, it would get you around some of the backwards incompatibility problems, and it would allow you to introduce API points that aren't "relational" in their intention. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
