Hey all, If you saw my email last week you know that my goal for the bulk of the GSOC work was going to be refactoring the Query class to be less SQL/relational db specific. After spending much of last week taking a few different approach at this it's become clear to me that that approach would result in very high up time costs. After speaking with Russell I've changed up the project plan somewhat. I'm going to start with actually creating the backend (MongoDB) and deal with most of the difficulties with things like insertion, updates, and everything mostly unrelated to the Query class. And after that's more or less done I'll move on to the complex refactorings.
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. If you have any questions, just ask. 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.
