On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > Hi Alex, > > On Jun 7, 9:35 pm, Alex Gaynor <alex.gay...@gmail.com> wrote: >> As you can see the fruits of these efforts have already begun to land >> in my branch, and I suspect that the multidb refactorings of last year >> have left us in a better state than I appreciated: while the concepts >> and data structures used in the Query class are relational/SQL biased >> (joins, where vs. having, etc.), the data itself is entirely backend >> neutral. This means that getting a "stupid" MongoDB backend that can >> handle trivial filters should be relatively easy, and then it can be >> evolved to work with the better datastructures I'll be refactoring >> Queyr to eventually use. > > Did you already take a look at our MongoDB backend for Django-nonrel: > http://github.com/aparo/django-mongodb-engine > This could save you some time. > > Also, maybe you'll find it helpful to see what we had to change in > Django to get that backend to work: > https://docs.google.com/leaf?id=0B3LqunL-SCJJNTNiNWE3ZmUtYWIxZi00ZWExLTk4YTktYjM4MzNiZTA0MGNh&hl=en > I guess by now you're not suprised by the size of the patch, > anymore. ;) You'll certainly find a few similarities to your branch > (like the AutoField change or has_results()). > > Couldn't some parts of has_results() be reused by NoSQL backends? For > example, clear_ordering() and set_limits() are completely independent > of the backend itself. >
Maybe, but that's really a backend level semantic, it's a trivial amount of code so I'm not going to worry about some abstraction for it. > Why did you revert the AutoField patch? BTW, in the Django-nonrel > patch you'll find a few other changes which were related to AutoField: > ForeignKey needs to find out the actual database type instead of > having a hard-coded IntegerField. We added related_db_type() for this > purpose. Maybe you can reuse or adapt some of our code. Still, Django > has a few unit tests which assume that assigning a string to an > AutoField will fail, so we'll need to find a solution for that > (probably by fixing the unit tests). > No, the unittests are quite correct in this instance. I've gone back and forth on this, but I believe the semantics of AutoField are "auto incrementing field" not "automatically assigned field", and as such the integer validation (and the fact that it occurs early) is a part of the API and semantics and the tests are correct. Therefore it's my intent to add an NativeAutoField, which is basically whatever the DB's native auto field is, and has corrospondingly looser constraints, pending a discussion with Russ. > 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. > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
