Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Django: queryset-refactor branch merged into trunk (djangoproject.com)
19 points by naish on April 27, 2008 | hide | past | favorite | 12 comments


This is newsworthy because it's the first time a branch created by Subversion was successfully merged back to trunk.


Do people really have that big of problems with svn?

I have used it for quite a few years and never really had too many problems. It isn't the ideal system, git may be getting close to that, but it works.

Maybe I just look at it differently - I have a few friends who work somewhere that still uses Microsoft VSS.


We use SVN exclusively for our projects at NeoSmart Technologies (private and public); and a huge number of highly-popular open source communities are also built around SVN...

Examples similar to Drupal: WordPress, Gallery2, etc.


Certainly a lot of projects use svn, even Django back to this original thread. I think every Python library I use is checked out of svn.

So do people just like to joke how it is so unusable? Or is there some glaringly obvious thing I am missing?


It's not that SVN is particularly bad for merging; it's that bzr and git are so much better at it.


This is one of the major 1.0 goals for Django... Awesome, I think newforms-admins still has to be merged with trunk...

Can you smell it??? (Django 1.0)


For people who have not been keeping up. What does this exactly mean? I looked in the Doc and couldn't find a link to anything about the queryset-refactor



Thanks for the links.

1.order_by fixing: I always run into problems with it, this is much needed

2.model inheritance: finally!

3.querysets not loaded into memory: yay! I do some hackery around the old way that I can remove.

4.slicing to the end: nice, again this commonly results in a big of uglyness getting the total size of the queryset

5.reverse? nice feature to have. So if you order by date you can quickly reverse the order.

6.values retrieving through FK? Amazingly useful. If you don't already use values, I strongly suggest looking into it. For large sets of data it is a must-have feature, you can load a minimal amount of data. I do this for things like mapping a number of points, I just grab the id and lat/long. However, now I can simplify that function since I can grab values across FK's.

7.Values list? Actually somewhat handy, depending on the application. Dictionary is nice for my previous example of using values.

8.Restrictive select related? Very cool, you can do some optimization by providing a list of what you actually want to get.

9.None check? Perfect, I much prefer that syntax to the blah__isnull=True.

10. Update for a queryset? Very nice - will consider how to use this to optimize some work. So instead of saving individual objects you could do one big update.

11. Q class improvements? I currently don't use Q's, but with this added functionality I may revisit that.

Overall this looks great. Many positive improvements, and a very logical upgrade to Trunk. I imagine once the newforms admin makes use of this and integrates the model inheritance it will also be merged in.


it means that the bulky-but-workable version of what generated django's db queries has been replaced my malcolm tredinnick much more advanced refactor.

for details on the refactor and why it should matter to you, check out: http://www.pointy-stick.com/blog/2008/03/11/queryset-impleme...

and, needless to say, kudos to malcolm for this massive undertaking! hes certainly helping take django to the next level of ubiquity.


looks like i got ahead of myself and the link was posted in the comment i was replying to.. i guess that speaks to the importance of reading it ;)





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: