Opened 7 years ago

Closed 7 years ago

#5498 closed (wontfix)

GeoDjango not compatible with PostGIS 1.1.0

Reported by: jbronn Owned by: jbronn
Component: GIS Version: gis
Severity: Keywords: gis sprint geodjango postgis
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: UI/UX:

Description

Matthew Wensing posted this message on django-dev. There are hardcoded 'ST_' references in [browser:django/branches/gis/django/contrib/gis/geos/base.py GEOS base.py] and in [browser:django/branches/gis/django/contrib/gis/db/backend/postgis/field.py PostGIS spatial backend] that should be fixed.

Attachments (1)

gis_5498.diff (1.5 KB) - added by rcoup 7 years ago.
use GEOM_FUNC_PREFIX in backend.postgis.field

Download all attachments as: .zip

Change History (6)

Changed 7 years ago by rcoup

use GEOM_FUNC_PREFIX in backend.postgis.field

comment:1 follow-up: Changed 7 years ago by rcoup

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

See attached patch that uses GEOM_FUNC_PREFIX for Transform() in the backend.

I can't see where GEOSGeometry.getquoted() is ever used, and I'm reluctant to add GEOM_FUNC_PREFIX because it'll then couple GEOS to the postgis backend (I use geos on non-postgis machines because it's so damn handy). Surely if it is needed (it may be a leftover remnant?) it should be part of the backend, not put into the geometry objects?

comment:2 Changed 7 years ago by jbronn

  • Triage Stage changed from Unreviewed to Accepted

comment:3 in reply to: ↑ 1 Changed 7 years ago by jbronn

Replying to rcoup:

I can't see where GEOSGeometry.getquoted() is ever used, and I'm reluctant to add GEOM_FUNC_PREFIX because it'll then couple GEOS to the postgis backend

GEOSGeometry.getquoted() is only used by the psycopg2 adapter. When psycopg2 sees an object in its parameters (e.g., execute(sql, params)), it checks to see if it has the __conform__ method, and uses the getquoted routine for the quoting of the object for PostgreSQL.

I'm with you on the GEOS dependency issue -- I always attempt to keep the GEOS module as loosely coupled as possible. I will most likely place the import in a try/except to maintain this (nothing will be broken since it's only needed when used w/postgres).

comment:4 Changed 7 years ago by jbronn

  • Needs tests set

r6508 should fix this, but compatibility is not yet confirmed.

comment:5 Changed 7 years ago by jbronn

  • Resolution set to wontfix
  • Status changed from new to closed

GeoDjango should theoretically be compatible with PostGIS 1.1.0, but I do not have the time to test. As time marches on, this type of compatibility is less important as people migrate their installations to 1.2 and above (currently at 1.3.2). Thus, I won't fix this unless compelled otherwise.

Note: See TracTickets for help on using tickets.
Back to Top