[Django] #22352: GeoQuerySet methods: support lookups on reversed o2o relationships as field_name
Django
field_name
----------------------------+------------------------------------
Reporter: pchiquet | Owner: nobody
Type: Bug | Status: new
Component: GIS | Version: master
Severity: Normal | Keywords: geodjango, GeoQuerySet
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
----------------------------+------------------------------------
GeoQuerySet methods, for example ''distance'', are performed on a given
geographic field of the model.
The geographic field to use can be specified thanks the '''field_name'''
argument. '''field_name''' can be a field directly in the model or a
lookup to a related field in another model (such as,
{{{'address__point'}}}). However '''lookups with reversed one to one
relation are not supported'''.
For example, with the following model:
{{{
#!python
class User(Model):
pass
class UserProfile(NamedModel):
user = models.OneToOneField(User)
point = models.PointField()
}}}
the following spatial operation on User fails:
{{{
#!python
User.objects.all().distance(Point(1,1),
field_name='userlocation__point')
}}}
and raises the following exception:
{{{
Traceback (most recent call last):
(...)
File "django/contrib/gis/db/models/query.py", line 104, in distance
return self._distance_attribute('distance', geom, **kwargs)
File "django/contrib/gis/db/models/query.py", line 593, in
_distance_attribute
procedure_args, geo_field = self._spatial_setup(func,
field_name=kwargs.get('field_name', None))
File "django/contrib/gis/db/models/query.py", line 466, in
_spatial_setup
raise TypeError('%s output only available on GeometryFields.' %
func)
TypeError: ST_Distance output only available on GeometryFields.
}}}
The lookup is supported only if the foreign key is in the Queryset model.
I think it would be nice to support reversed relations too.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: Bug | Status: assigned
Component: GIS | Version: master
Severity: Normal | Resolution:
Keywords: geodjango, | Triage Stage:
GeoQuerySet | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Pierre Chiquet):
* owner: nobody => anonymous
* status: new => assigned
* needs_docs: => 0
* needs_tests: => 0
* needs_better_patch: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:1>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: Bug | Status: assigned
Severity: Normal | Resolution:
Keywords: geodjango, | Triage Stage:
GeoQuerySet | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by Pierre Chiquet):
Proposed patch:
https://github.com/pchiquet/django/commit/d583c5bdd2317a9e1921c80d475f13eba8cb7f71
The git branch: https://github.com/pchiquet/django/tree/ticket_22352
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:2>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Component: GIS | Version: master
Severity: Normal | Resolution:
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by bmispelon):
* type: Bug => New feature
* stage: Unreviewed => Accepted
Comment:
Hi,
This seems like a sensible feature to have so I'll move the ticket to
"accepted".
The next step is to find someone familiar with the GIS codebase to review
your patch and move the ticket to "ready for checkin".
Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:3>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by amirrustam):
I think the request should also support reverse OneToMany relationships.
This Stackoverflow question is relevant:
http://stackoverflow.com/questions/25047964/geodjango-geoqueryset-
distance-results-in-st-distance-output-only-available-o
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:4>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: 0 => 1
Comment:
This will require some changes after the
[https://github.com/django/django/pull/3114 _meta refactor branch] is
merged. Please send a pull request if you can update your patch after
that.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:5>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by mitar):
* cc: mmitar@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:6>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by kostko):
* cc: jernej@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:7>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by mitar):
This would be really cool to have. Including the OneToMany support.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:8>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Component: GIS | Version: master
Severity: Normal | Resolution: wontfix
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* status: assigned => closed
* resolution: => wontfix
Comment:
I have tested this with my branch which replaces `GeoQuerySet` methods by
model functions (#24214). And this was not a problem at all, be it with
OneToOne or with OneToMany relations. The syntax will be
`User.objects.all().annotate(dist=distance('userlocation__point',
Point(1,1)))`
I'll close this one as won't fix, as I think it is not worth working on
to-be-deprecated code. The aforementioned branch is waiting for someone
knowledgeable with Oracle GIS to write the Oracle support.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:9>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by artscoop):
The model functions are to be introduced in Django 1.9, and the to-be-
deprecated code is still present in Django 1.8 (with LTS). I'm convinced a
wontfix is not a good move here.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:10>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
Sorry, but unless this is a regression, it has no chance to enter Django
1.8.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:11>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
Also note that if you really need this functionality, it might be possible
to adapt [d9ff5ef36d3f714736d633435d45f03eac9c17b5] to make it a third-
party app usable from Django 1.8.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:12>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by artscoop):
This may not be a regression, but I'm sure it's a bug. The `field_name`
exposes the possibility to span across relationships. It works with
`ForeignKey`s, but not with `OneToOneField`s, which does not make much
sense. (The bug occurs because of the way the {{{"field__field__etc"}}}
relationship span is processed).
If a fix won't make it to Django 1.8 (there is a fix here:
[https://github.com/django/django/compare/master...pchiquet:ticket_22352])
I can still have a look at the dev version of Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:13>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
If it's not a regression from a previous release or a major bug in a new
feature it won't be backported. See our
[https://docs.djangoproject.com/en/dev/internals/release-process
/#supported-versions supported versions policy].
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:14>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by pembo13):
I see this is marked as wontfix, but there seems to be no intermediate
solution. Do OneToOne relationships simply not work with GIS in Django?
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:15>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by pembo13):
Replying to [comment:9 claudep]:
> I have tested this with my branch which replaces `GeoQuerySet` methods
by model functions (#24214). And this was not a problem at all, be it with
OneToOne or with OneToMany relations. The syntax will be
`User.objects.all().annotate(dist=distance('userlocation__point',
Point(1,1)))`
>
> I'll close this one as won't fix, as I think it is not worth working on
to-be-deprecated code. The aforementioned branch is waiting for someone
knowledgeable with Oracle GIS to write the Oracle support.
So what do we about this in Django 1.8?
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:16>
Django
field_name
Reporter: pchiquet | Owner: anonymous
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: geodjango, | Triage Stage: Accepted
GeoQuerySet |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
See comments twelve and fourteen.
--
Ticket URL: <https://code.djangoproject.com/ticket/22352#comment:17>