ForeignKey(unique=True) and ForeignRelatedObjectsDescriptor
Jeremy Dunck
class Place(Model):
...
class Retaurant(Model):
place = ForeignKey(Place, unique=True)
....
Currently, if you have a place reference and want to get to the (0 or
1) restaurant, you do something like this:
r = place.restaurant_set.get()
Slightly more idiomatic w/ related_name
r = place.restaurants.get()
I think it'd be nice to have this instead:
r = place.restaurant
As far as I can tell, this would be a one-line change to
ForeignRelatedObjectsDescriptor.__get__.
... I have the feeling I brought this up with someone before, but I
can't find the thread and might just be hallucinating.
Malcolm Tredinnick
> Consider:
>
> class Place(Model):
> ...
>
> class Retaurant(Model):
> place = ForeignKey(Place, unique=True)
> ....
>
> Currently, if you have a place reference and want to get to the (0 or
> 1) restaurant, you do something like this:
>
> r = place.restaurant_set.get()
>
> Slightly more idiomatic w/ related_name
>
> r = place.restaurants.get()
>
> I think it'd be nice to have this instead:
>
> r = place.restaurant
I think it would be bad to have that. Now you have reverse ForeignKey
relationships returning two different things, depending only on whether
it's unique or not. Inconsistent. I see this as the one argument for
keeping OneToOneField around: it will return the object.
So I'm -1 on this.
Malcolm
--
A conclusion is the place where you got tired of thinking.
http://www.pointy-stick.com/blog/
Thomas Guettler
> Consider:
>
> class Place(Model):
> ...
>
> class Retaurant(Model):
> place = ForeignKey(Place, unique=True)
> ....
You can use a property. Code not tested:
class Place(Model):
def get_restaurant(self):
try:
return Restaurant.objects.get(place=self)
except Restaurant.DoesNotExist:
return None
restaurant=property(get_restaurant)
Thomas
Jeremy Dunck
Of course. I just have about 30 places to do that legwork, which seems silly.
I understand Malcolm's argument, though. This is why I asked rather
than just making the small change in my local Django and changing all
my client code to assume it.
Marty Alchin
>
> On 11/6/07, Thomas Guettler <h...@tbz-pariv.de> wrote:
> >
> > You can use a property. Code not tested:
>
> Of course. I just have about 30 places to do that legwork, which seems silly.
Well, you could write up a function to create the property for you, so
that you don't need quite as much boilerplate. Here's how I figure it
might look.
class Place(models.Model):
restaurant = make_property('restaurant_set')
I'm sure you can fill in the rest if that approach interests you.
-Gul
Tai Lee
mapping they did, as in the OP's example. I was told that OneToOne
didn't work in some cases and was going away, and that I should use
ForeignKey(unique=True) instead.
If there are technical problems with OneToOne and
ForeignKey(unique=True) can behave like OneToOne without those
problems after minimal changes as suggested here, we should go for it.
On the other hand, if there's a preference to bring OneToOne back and
fix any problems it has, I'm all for that as well.
Malcolm Tredinnick
So if OneToOneField was able to handle pk=False (currently it's always
the primary key) and othwerwise behaved as a reference that was unique
on both ends, including being able to be addressed across the reverse
relation, does that meet your needs?
That's mostly compatible with what OneToOne does now and I can't think
of much else it might need. We need to knuckle down and fix the whole
"semantics might change" issue on that field at some point prior to 1.0
and I'm kind of in "get stuff needed before 1.0 done" mode at the
moment.
I'm not going to leap in and do this immediately, because we need a few
more maintainers to check for downsides, but it's the kind of rough idea
I've had in mind for this field for a little while and it hasn't sounded
too stupid in the past.
Regards,
Malcolm
--
Despite the cost of living, have you noticed how popular it remains?
http://www.pointy-stick.com/blog/