On Wed, 2007-03-21 at 18:10 +0000, jbronn wrote: > > It's sleeping right now. The upcoming refactoring of Django's QuerySet > > mechanism looks like it'll make working with other ORMs a bit easier, > > so if someone wants to come back and revisit it then it'd be a bit > > less of an ambitious project ;) > > Is there any place (e.g. a trac page) where interested parties can > check out the progress on the QuerySet refactor? Since I recently > completed PostGIS integration for the GeoDjango branch (will be > committed to SVN branch pending Jeremy Dunck's approval), I have an > active interest in what you guys plan on doing in there.
Not yet. I'll put up a wiki page when I get a chance. Haven't been working on this lately, since I've been putting my idle cycles into getting ready for 0.96. That seems to be settled now, so I can go back to this. Will try to get something up tomorrow or on the weekend. I assume you've read the original thread on this (http://groups.google.com/group/django-developers/browse_frm/thread/691da1d6e3b0661d/a52efdfd1bca037a?lnk=gst&q=QuerySet&rnum=1#a52efdfd1bca037a )? That describes the approach. The rough first pass that Honza Kral posted later in the thread is surprisingly close to what I've written as well. The actual implementation is really a two-pass process: first just a refactoring so that we split out the database-dependent bits into a Query set class that is used inside QuerySet, etc. This would be more or less bug-for-bug compatible with existing code (it might fix a bugs in passing; I'm not going to concern myself too much with not accidently fixing bugs). Pass two is then making sure we fix the couple of dozen open SQL generation bugs. This was really the motivation for the refactor, since it's currently very hard to tweak SQL generation (as you've no doubt noticed) in the current form. Hopefully you're also aware that Jeremy's and I have had a short discussion on this list (in the above thread, towards the end) about how to have the GIS fields generate the right SQL, since they're different from other fields. I'm still not completely in love with the solution we settled on, but I am aware of it, so I'll keep an eye on your branch as well to help make any transition easier. Anyway, like I said, since 0.96 is out the door, I'm going to ease back a little (not completely,obviously) from only fixing other peoples' problems and do some development work of my own and this is one of the things I'll be working on. > On a related note, Brian Beck has some implementation ideas on how > he'd go about integrating SQLAlchemy: > http://blog.case.edu/bmb12/2007/03/thinking_about_taking_over_the_djangosqlalchemy_branch Yeah, I saw that. Not sure I'd use exactly the approach he's advocating -- I suspect he's splitting off at too high a level, since there's not that much database dependency up at the model layer -- but it's not a bad way to approach the problem and certainly has the "working in increments" good feeling about it. Will be interesting to see what happens. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
