Re: Django-nonrel patches
Hi Daniel, Thanks for giving some feedback on this. I completely agree that one of its biggest downfalls is that it tries to treat MongoDB as a relational store, and I think this is what I meant by it just didn't "feel right". Also +1 on the comments made about it feeling hacky, and I suspect that if Mongo ever made it into the Django core, it would be redesigned and re-implemented from scratch. I'd love to see Mongo in the Django core one day, but not as django-nonrel. Cal On Sun, Jun 24, 2012 at 5:47 AM, Daniel Greenfeld 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. > 2. django-nonrel is unsupported. It switched maintainers and the > current maintainer is not working on it. > 3. [pydanny opinion warning] django-nonrel wasn't adopted in Django > core because it lacked adequate documentation and tests. > 4. [pydanny opinion warning] django-nonrel treats MongoDB as a > relational store, which it most certainly is not. > 5. [pydanny opinion warning] django-nonrel smells like a giant hack > done by very well intentioned people.. > > Hope that helps, > > -- > 'Knowledge is Power' > Daniel Greenfeld > http://pydanny.com > > -- > 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. > > -- 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.
Re: Django-nonrel patches
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 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. > 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. > 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? > > Hope that helps, > > -- > 'Knowledge is Power' > Daniel Greenfeld > http://pydanny.com -- 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.
Re: Proposal: Add some extensibility / decoupling features to Django templates
On Sat, Jun 23, 2012 at 7:17 PM, Yo-Yo Ma wrote: > Without changing any of the existing functionality or settings in Django, > refactor the template system to use an ``Environment`` class (something akin > to Jinja2's ``Environment``) which takes a list of loaders, and a number of > other arguments. Then, instantiate this class, using the provided settings, > and use it for all the default functionality (the admin, render_to_response, > CBV template access, etc.). This would allow developers to make their own > ``Environment`` instance with different arguments, request-specific or > otherwise, and without having to do a lot of evil things. Sounds great - I'd love to see a patch! Jacob -- 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.
Re: Proposal: Add some extensibility / decoupling features to Django templates
On Sun, Jun 24, 2012 at 2:50 PM, Jacob Kaplan-Moss wrote: > On Sat, Jun 23, 2012 at 7:17 PM, Yo-Yo Ma > wrote: > > Without changing any of the existing functionality or settings in Django, > > refactor the template system to use an ``Environment`` class (something > akin > > to Jinja2's ``Environment``) which takes a list of loaders, and a number > of > > other arguments. Then, instantiate this class, using the provided > settings, > > and use it for all the default functionality (the admin, > render_to_response, > > CBV template access, etc.). This would allow developers to make their own > > ``Environment`` instance with different arguments, request-specific or > > otherwise, and without having to do a lot of evil things. > > Sounds great - I'd love to see a patch! > > Jacob > > -- > 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. > > This is a good idea, I think there's even a ticket (probably, but not definitely filed by either myself or Carl Meyer) on this! Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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.
Re: Django-nonrel patches
On Sun, Jun 24, 2012 at 10:31 PM, Adam "Cezar" Jenkins 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 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.
Re: Django-nonrel patches
On Sun, Jun 24, 2012 at 6:33 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Sun, Jun 24, 2012 at 10:31 PM, Adam "Cezar" Jenkins > wrote: > > 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. > > This is my biggest issue with nonrel at this point. The API is generic for multiple backends (mongo and appengine). To do so there are layers of abstraction. In general, I think if you have a backend that's only 95% compatible you can lose a lot of good things. I have an app that is helped out a lot by something like mongo. For instance an app that allows students to apply to a university. Storing someone's application as a single document has much less maintenance headaches than a much more normalized schema that includes a dozen models. This isn't a high scalability scenario though. So I'd also like to use other 3rd party apps like django-socialauth without have to do too much hacking onto it. If I wanted to use a good bit of the 3rd party apps out there, I'd have to do a non-trivial amount of hacking to get it done. Django-nonrel helps with most of this, but since dealing with a nonrel db backend against the django ORM is a mess out of necessity, it's really hard to go in and impliment something like manytomany emulation. Which is quite possible in theory and useful in non-scalable scenarios. It would be great to have something that really only requires exchanging the import of django.db.model with nonrel.db.models. If the only interaction you have to deal with is a higher level API, then maybe the backend code could be more flexible and maintainable? > 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. > > -- 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.
