On Dec 16, 2010 7:20 PM, "Christophe Pettus" wrote:
>
>
> 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 ope
On Dec 17, 9:21 am, Carl Meyer wrote:
> Instance._state.adding is new in 1.2 (in 1.2 it was instance._adding
> and only ever monkeypatched onto a model instance by ModelForm; I
> changed it to instance._state.adding and encapsulated it inside the
> ORM just a few weeks ago in r14612).
Oh - and
Hi Luke,
On Dec 16, 9:47 am, Luke Plant wrote:
> For the latter, I think we should use instance._state.adding to reliably
> detect whether a PK has been set or not. This could cause some
[snip]
> While I was there, I fixed _get_next_or_previous_by_FIELD to use
> self._state.adding, rather than
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
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
12 matches
Mail list logo
