ticket 4789: select_related + depth bug, apply the patch?
Gábor Farkas
ticket 4789 fixes a bug in select_related-queries when used with the
depth parameter.
it contains a patch which fixes the problem. it also contains the tests
for this fix.
without this patch, select_related is unusable with the depth parameter.
i understand that everyone has limited time etc, but the patch has been
lying there for two weeks, it's a simple change, so could maybe someone
look at it, and commit it or comment on it?
thanks,
gabor
Malcolm Tredinnick
My personal stance on this is that I'm not applying it, since I'm
spending all available moments rewriting the code it applies to. It's
not being ignored. The problem is noted. The exact fix isn't appropriate
in my world at the moment.
Somebody else may want to apply it, though. I obviously don't speak for
anybody by myself.
Regards,
Malcolm
Gábor Farkas
> On Fri, 2007-07-27 at 08:55 +0200, Gábor Farkas wrote:
>> hi,
>>
>> ticket 4789 fixes a bug in select_related-queries when used with the
>> depth parameter.
>>
>> it contains a patch which fixes the problem. it also contains the tests
>> for this fix.
>>
>> without this patch, select_related is unusable with the depth parameter.
>>
> spending all available moments rewriting the code it applies to. It's
> not being ignored. The problem is noted. The exact fix isn't appropriate
> in my world at the moment.
>
> Somebody else may want to apply it, though. I obviously don't speak for
> anybody by myself.
approximately when do you plan to finish this rewrite? i realize it's
hard to predict, i'm just asking for very rough estimates... are we
talking about days or weeks or months?
thanks,
gabor
Jacob Kaplan-Moss
> approximately when do you plan to finish this rewrite? i realize it's
> hard to predict, i'm just asking for very rough estimates... are we
> talking about days or weeks or months?
As a general rule we don't give time estimates. Seems the best way to
jinx something is to promise to have it done by some arbitrary date...
If Malcolm wants to commit to a timeline that's his choice, but if he
does I'll certainly laugh at him... there may be some pointing and
laughing, and even some side-slapping, too.
<grin>
Jacob
Gábor Farkas
:)
i know. i was only asking because the argument seems to be that:
- my rewrite will fix the problem too (and probably in a better way), so
i won't apply this patch.
but this only works if the rewrite ends relatively soon. in other words,
if the rewrite is planned to take months, then i still think it's better
to have something that works, than to have something that does not work.
especially if it's such an big problem.
or, alternatively would a documentation-patch that marks the depth-param
as "DOES NOT WORK, DO NOT USE IT" have a chance to get accepted? :))
p.s: of course, malcolm is the one with commit-rights not me. i
completely respect his decision.
gabor
Malcolm Tredinnick
Asking for rough timelines isn't a completely insane question and I
don't view it as rude in any way (some projects you never ask; here, I
think you can ask, but don't be holding your breath for an answer).
Asking for accurate timelines would be insane, but you can wonder when
something might be done. Of course, I might not answer. :-)
Right now it's probalby 80% to "functional" (replicates existing
functionality, is understandable and fixes a couple of the more
egregious bugs). It's my most active big project at the moment and I
hope to finish it this week, since I'm technically on vacation. I
haven't rewritten the select-related query generation yet, but that's
mostly because I haven't gotten that far (I have a list and I'm working
through it). Getting existing functionality replicated is a point at
which we can start to consider checking in the changes -- although
there'll no doubt be some discussion on here first.
With regards to your particular patch, at the moment I would rather put
any free time I have into working on the rewrite than evaluating,
reviewing and tweaking a patch to fix the old stuff. That's what I've
chosen to do. Like I said, though, other maintainers may choose to
commit it on a temporary basis, but I don't have enough extra free time
to do that at the moment.
Regards,
Malcolm