On Dec 16, 2010, at 2:31 PM, Luke Plant wrote:
> That being so, there is a case for arguing that
> ForeignRelatedObjectsDescriptor should not retrieve objects where the
> field pointed to is NULL - for consistency with the inverse operation.
I agree with this. If the FK field is NULL, it should
On Thu, 2010-12-16 at 11:30 -0800, Christophe Pettus wrote:
> On Dec 16, 2010, at 11:14 AM, Luke Plant wrote:
> > This isn't true if the field pointed to (i.e. primary key by default)
> > allows NULL values - in that case a ForeignKey field with a NULL value
> > can and should return a non-empty se
I'm in favor of the patch you've provided, Luke. Raising an exception seems
like the best option here to me.
While it *is* a logical error to get the related objects of an unsaved
instance, the current behavior seems buggy and (as Ian Clelland points out)
it can be potentially harmful.
FWIW, I
I've been bitten by this behaviour before, with code that looked like
an_object.related_object_set.delete()
where the foreign key could be null.
On Thu, Dec 16, 2010 at 11:14 AM, Luke Plant wrote:
> On Thu, 2010-12-16 at 10:10 -0800, tonnzor wrote:
>> My idea was to fix this in a very straight
On Dec 16, 2010, at 11:14 AM, Luke Plant wrote:
> This isn't true if the field pointed to (i.e. primary key by default)
> allows NULL values - in that case a ForeignKey field with a NULL value
> can and should return a non-empty set of values when the related objects
> lookup is done.
If I'm unde
On Thu, 2010-12-16 at 10:10 -0800, tonnzor wrote:
> My idea was to fix this in a very straight way - change ForeignKey
> behavior (the piece of code that generates many_set method) - so it
> doesn't take into account null.
>
> Let me explain a bit more. If foreign key is null - then there's no
> l
My idea was to fix this in a very straight way - change ForeignKey
behavior (the piece of code that generates many_set method) - so it
doesn't take into account null.
Let me explain a bit more. If foreign key is null - then there's no
link between Many and One object. So it many_set should return
On Thu, 2010-12-16 at 10:56 +0100, Roald de Vries wrote:
> Now if I do:
>
> one = One()
>
> ... then:
>
> one.many_set.all()
>
> ... returns all Many's with 'self.one_id == None'.
>
> From an implementational (SQL) standpoint, this seems logical, but
> from an OO standpoint, it s
♫ Tom ♩ tie ♭♬ tom ♪
http://code.djangoproject.com/ticket/14910
On Dec 5, 11:37 am, Klaas van Schelven
wrote:
> Replying to myself here.
>
> I'm quite sure the docs are wrong by now.
>
> Also: I think the documented behavior is not desirable. Changing
> translations per-view makes for hard to de
Hi, for those of you that hasn't already heard, the "PSF Sprints"
charter is going to start funding any Python related Sprints,
including Django ones [1]. Cheers,
Iván
[1] http://pythonsprints.com/2010/12/15/widening-our-scope/
--
You received this message because you are subscribed to the G
Dear all,
I have a model with a foreign key with null=True:
class Many(Model):
ForeignKey(One, null=True)
class One(Model):
pass
Now if I do:
one = One()
... then:
one.many_set.all()
... returns all Many's with 'self.one_id == None'.
From an implementation
Made some comments about the bug and the patch.
The patch gives the right result, but the JOIN there is a bit weird.
On Dec 15, 7:54 pm, Philippe Raoult
wrote:
> I have produced a patch for this [1] long-standing SQL bug.
>
> The SQL produced with the patch is correct AFAIK, but my understanding
12 matches
Mail list logo
