Django 1.4: call for release blockers
Aymeric Augustin
1.4 beta arrived a bit late, but we'd like to catch up and release RC1 before the end of the month.
Until then, we're going to focus on:
1 - Release blockers:
https://code.djangoproject.com/query?status=!closed&severity=Release%20blocker
2 - RFC tickets -- unless they're new features:
https://code.djangoproject.com/query?status=!closed&type=Uncategorized&stage=Ready+for+checkin&or&status=!closed&type=Bug&stage=Ready+for+checkin&group=component
If you notice a bug in the beta that is:
- a major bug in a new feature, or
- a regression from 1.3, or
- a crashing bug, or
- a data loss bug,
then you should report it in Trac as soon as possible and set "severity" to "release blocker".
Thanks for helping us make Django 1.4 a high quality release!
Best regards,
--
Aymeric.
Anssi Kääriäinen
> Hello,
>
> 1.4 beta arrived a bit late, but we'd like to catch up and release RC1 before the end of the month.
>
> Until then, we're going to focus on:
>
There are two release blockers related to the new prefetch_related
feature which needs some attention.
The first one is out of my comfort zone: it is about what DB to use
for prefetching when .using() has been called for the main queryset.
Currently the database which happens to be in use for the related
queryset will be used. That is, the main queryset's .using() has no
direct effect for the prefetch. Maybe use the database of the main
queryset if the related queryset doesn't _explicitly_ use any
database? I really don't know this area. I checked the original ticket
for prefetch_related and the conclusion there was that lets leave this
for later, we don't know this area. Any multidb-people willing to
help? The ticket is #17696.
The second one is about .iterator() and .prefetch_related()
interoperability. They are mutually exclusive (you need to fetch all
the objects before you can do prefetch. However, .iterator() says do
not fetch all the objects in one go...). There are basically three
ways forward: raise an error, favor .iterator() (current behavior) or
favor .prefetch_related().
I think each one has some merit, and this is mostly bike-shedding.
However, if you have good reasons for one of the options it would be
good to hear them now. I would prefer either error or doing the
prefetch even when iterator is used. As I don't recall ever actually
using .iterator() in production I have no strong opinions. The ticket
is #17668.
- Anssi
Carl Meyer
Hash: SHA1
Hi Anssi,
On 02/18/2012 05:37 AM, Anssi K��ri�inen wrote:
> The second one is about .iterator() and .prefetch_related()
> interoperability. They are mutually exclusive (you need to fetch all
> the objects before you can do prefetch. However, .iterator() says do
> not fetch all the objects in one go...). There are basically three
> ways forward: raise an error, favor .iterator() (current behavior) or
> favor .prefetch_related().
>
> I think each one has some merit, and this is mostly bike-shedding.
> However, if you have good reasons for one of the options it would be
> good to hear them now. I would prefer either error or doing the
> prefetch even when iterator is used. As I don't recall ever actually
> using .iterator() in production I have no strong opinions. The ticket
> is #17668.
I don't have a real strong opinion here either, but I think this rarity
of usage of .iterator() is an argument for favoring it. In my
experience, if you are bothering to use .iterator() it's because you
really know you need it; you are fetching a ton of items and loading
them all at once might run your server out of memory. Whereas the
consequence of ignoring prefetch_related is just extra SQL queries -
bad, but less likely to be catastrophic.
That's all kind of handwavy, but in the absence of good hard reasons in
either direction, it's the best I've got :-)
Really, silently ignoring either one gives me a bit of a bad taste. I
understand Luke's reasoning for not raising an error; you might not
control the whole queryset construction chain, and unpredictable errors
are bad. But I wish there were some way we could alert the developer of
the situation.
I guess anyone who really needs the prefetch_related is probably
monitoring their SQL queries, and is likely to notice the extra SQL
queries pretty quickly.
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9BJeUACgkQ8W4rlRKtE2fcjgCbBudTE6UjRCTRashf6mZ5PNzI
toUAnRIatUAfQVw33mlbAp6W3Mx0ofHg
=UCkj
-----END PGP SIGNATURE-----
Carl Meyer
Hash: SHA1
On 02/19/2012 09:40 AM, Carl Meyer wrote:
> On 02/18/2012 05:37 AM, Anssi K��ri�inen wrote:
>> The second one is about .iterator() and .prefetch_related()
>> interoperability. They are mutually exclusive (you need to fetch all
>> the objects before you can do prefetch. However, .iterator() says do
>> not fetch all the objects in one go...). There are basically three
>> ways forward: raise an error, favor .iterator() (current behavior) or
>> favor .prefetch_related().
>
>> I think each one has some merit, and this is mostly bike-shedding.
>> However, if you have good reasons for one of the options it would be
>> good to hear them now. I would prefer either error or doing the
>> prefetch even when iterator is used. As I don't recall ever actually
>> using .iterator() in production I have no strong opinions. The ticket
>> is #17668.
>
> I don't have a real strong opinion here either, but I think this rarity
> of usage of .iterator() is an argument for favoring it. In my
> experience, if you are bothering to use .iterator() it's because you
> really know you need it; you are fetching a ton of items and loading
> them all at once might run your server out of memory. Whereas the
> consequence of ignoring prefetch_related is just extra SQL queries -
> bad, but less likely to be catastrophic.
>
> That's all kind of handwavy, but in the absence of good hard reasons in
> either direction, it's the best I've got :-)
Actually, another reason to favor .iterator is that it's a terminal
clause. So in any situation where iterator and prefetch_related are both
used, iterator must have been used last. So favoring .iterator favors
the most recent request, and in the hypothetical "you got the queryset
from some other library" situation, favors the integrating developer's
request.
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9BJ3gACgkQ8W4rlRKtE2djBwCeIQiWCfmazZ2clfkkrCcEqV6C
g48An3q2IowQsgW5Q2zaYkDsNuY4BQRM
=SeV6
-----END PGP SIGNATURE-----