Queryset Refactor (qs-rf)
Rob Hudson
I listened to the This Week in Django podcast with Malcolm (great show
guys!) and was encouraged to test out the qs-rf branch on a couple
projects I have running. Can I simply checkout the branch, change my
Python path to pull the django folder from that branch, and I'm good
to go? Are there any code changes required?
I'm assuming this is all it takes. From the podcast Malcolm made it
sounds like it's backward compatible. But just thought I'd ask.
Also, is it helpful to do this? Should we encourage others to do the
same?
Cheers!
-Rob
Ben Ford
A nice trick for using testing lots of banches is to use a django.pth file in your /usr/lib/python2.x/site-packages, (assuming *nix usage) like so:
#trunk
/path/to/django/trunk
#qsrf
#/path/to/django/branches/qsrf
#other branches here...
Then to change branches you just need to comment/uncomment the relevant line in the django.pth file.
As for helpfulness/encouragement, I couldn't really say :-)
Hope that's useful,
Ben
Regards,
Ben Ford
ben.f...@gmail.com
+447792598685
Rob Hudson
> A nice trick for using testing lots of banches is to use a django.pth file
> in your /usr/lib/python2.x/site-packages, (assuming *nix usage) like so:
me:
sudo rm /opt/local/lib/python2.4/site-packages/django
sudo ln -s ~/sandbox/django_trunk/django /opt/local/lib/python2.4/site-
packages/django
1 for trunk and 1 for 0.96 for some projects.
If I had my git repo like I'd like it, it could just "git branch 0.96"
and be golden, but I don't. :)
So, I think I may just go for it and see if anything breaks.
Thanks,
Rob
Rob Hudson
> If I had my git repo like I'd like it, it could just "git branch 0.96"
> and be golden, but I don't. :)
That should be "git checkout 0.96". (Sorry for the noise.)
-Rob
David Reynolds
Assuming it's an SVN checkout of trunk, you can do svn switch to the
qs-rf branch.
--
David Reynolds
da...@reynoldsfamily.org.uk
Malcolm Tredinnick
On Tue, 2008-03-11 at 10:34 -0700, Rob Hudson wrote:
> Hi devs,
>
> I listened to the This Week in Django podcast with Malcolm (great show
> guys!) and was encouraged to test out the qs-rf branch on a couple
> projects I have running. Can I simply checkout the branch, change my
> Python path to pull the django folder from that branch, and I'm good
> to go? Are there any code changes required?
>
> I'm assuming this is all it takes. From the podcast Malcolm made it
> sounds like it's backward compatible. But just thought I'd ask.
In theory it's backwards compatible for all sensible code. If you're
doing Tricky Stuff(tm), you may need to stay awake, but I've tried
pretty hard to keep everything the same. The public API on
django.db.models.query.Queryset is the same, the main things that are
called inside djang.db.models.options.Option are the same, which are the
two main areas.
There are some very minor internal backwards incompatibilities:
- the exception classed raised when you create a bogus query
(e.g. passing in an invalid field) has changed from TypeError to
a Django-specific FieldError class. This is for technical
reasons, not just because the error class was slightly
inappropriate.
- The save() method on models no longer takes "raw". That's for
internal use only and with the introduction of model inheritance
it was getting in the way of subclassing save() methods. The
functionality hasn't been lost however (using "raw" counts as
Tricky Stuff, so you can read the code to see what's going on
there).
- model inheritance is not expected to work in admin at the
moment. I'm still evaluating whether it's worth making it work
for existing admin or just write newforms-admin additions for it
at the right time. It's a new feature, so temporary lack of
admin support isn't going to break existing code and it requires
quite a bit of futzing around to make it work, so I'm not
viewing it as a showstopper if it turns out to be really
painful.
- if you were writing qs.filter(foo=None) (why???!) and
expecting it to always return nothing, it is now interpreted the
same as foo__isnull=True, so it might return something,
depending on circumstances. That was a change discussed here a
few months back and I've woven that slight backwards incompat
into the branch, rathe than on trunk.
Most of the other public-visible API changes are additions, rather than
changes. They're all marked as "New in Django development version" in
the docs, so diff the docs diretcory between trunk and the branch if you
want to see them.
At some point soon I'll update the wiki page with all this, but it
should be a case of "nothing needs to change" for most code. You might,
however, see some different results due to certain queries returning
better SQL (a.k.a. correct results) if, e.g., you're doing multiple
filters on many-to-many relations or exclude() filters. You might also
see some errors if you've been a bit lax and set up a recursive ordering
on a self-referential model (some of my code that I wrote a couple of
years ago actually fell into this trap). That's a bug in your code and
is easy to fix. For example, if Tag has a ForeignKey to 'self' called
"parent", then don't order by "parent", since that's infinitely
recursive (and it didn't do what you expect in the current code anyway),
but you could order by "parent__id" is your id values were sorted
appropriately in the database.
> Also, is it helpful to do this? Should we encourage others to do the
> same?
I think most bugs are in the corner cases now. I haven't yet got to the
point of declaring open season on testing on django-users, partly
because I only fixed one bug that was easy to stumble across yesterday
(and I didn't really need 60 bug reports about it) and I've still got
some work to do fine-tuning that. I also want to know in my own mind
what I'm going to do with model inheritance and admin, which I'm looking
at this week. However, that shouldn't stop people from testing it. I'm
particularly interested in regressions from existing code, since the
goal is to be pretty much fully backwards compatible for documented
stuff. I've already said to the people who've asked on django-users that
they should feel free to test and file bugs, some people are already
doing so.
Regards,
Malcolm
--
Why can't you be a non-conformist like everyone else?
http://www.pointy-stick.com/blog/
Malcolm Tredinnick
Oh, one other item:
- The OneToOneField class has changed slightly. I think the only
external difference is that it's no longer automatically a
primary key for the model (so you can have multiple
OneToOneField entries on a model). Since it wasn't documented
and people were warned off using it previously, this shouldn't
cause real hardship.
Malcolm
--
The sooner you fall behind, the more time you'll have to catch up.
http://www.pointy-stick.com/blog/
Justin Bronn
> me:
>
> sudo rm /opt/local/lib/python2.4/site-packages/django
> sudo ln -s ~/sandbox/django_trunk/django /opt/local/lib/python2.4/site-
> packages/django
>
merges between the branches. In light of Ben's `django.pth`
suggestion, I re-did it and decided to share:
http://www.djangosnippets.org/snippets/641/
`sudo chdjango.py gis`
-Justin
Ben Ford
I just had a quick scan over your snippet, but I don't see anywhere that the script is commenting out the current selection in django.pth. It looks like the script just appends another line to an existing file..? I'm not sure if I'm missing something, and I'm also not sure what python's behavior is likely to if there's more than one uncommented line in a .pth file. I would hazard a guess that it would just take the first one it comes to.
Cheers,
Ben
Justin Bronn
> I just had a quick scan over your snippet, but I don't see anywhere that the
> script is commenting out the current selection in django.pth. It looks like
> the script just appends another line to an existing file..?
'w')`, the 'w' mode tells Python to truncate the existing file ('wa'
would actually append to it). Thus, there's only one line in the
django.pth file, and no need to seek through and comment out lines.
Keeping the Django distributions in a single folder is conceptually
similar to maintaining a list of commented paths in `django.pth` --
just a bit more convenient.
-Justin
Ben Ford
Well, I'm lucky that's never caught me! Thank for pointing that out :-)
Ben