> Rather than flag "row_number()" as an extra_select parameter (and then
> try to clean up after it later), Oracle now just uses the default
> set_limits and clear_limits methods and does all extra query munging
> in its as_sql() method. And instead of doing an outer SELECT *, we
> SELECT specific columns (or aliases) by name and ignore our
> row_number() column, which is only used in the WHERE clause.
>
> This seems to fix most of the failures. I'll check it in soon when
> I'm sure it's not causing any new problems.
>
This approach breaks slicing for Oracle in GeoDjango. Specifically,
getting rid of the `SELECT *` and manually specifying the columns has
introduced side effects. The following example will show the problems
-- here is a simple geographic model:
class City(models.Model):
name = models.CharField(max_length=30)
point = models.PointField()
objects = models.GeoManager()
In 8425, here's the SQL that `City.objects.all()[0]` would produce:
SELECT * FROM (SELECT (ROW_NUMBER() OVER (ORDER BY "GEO_CITY"."ID" ))
AS "RN", "GEO_CITY"."ID", "GEO_CITY"."NAME",
SDO_UTIL.TO_WKTGEOMETRY("GEO_CITY"."POINT") FROM "GEO_CITY") WHERE rn
> 0 AND rn <= 1
As you can see, I need to wrap the geometry column with a function
call that converts the column into an acceptable format. With the
changes in r8445, this is the broken SQL that is produced:
SELECT "ID", "NAME", "POINT") FROM (SELECT ROW_NUMBER() OVER (ORDER BY
"GEO_CITY"."ID") rn, "GEO_CITY"."ID", "GEO_CITY"."NAME",
SDO_UTIL.TO_WKTGEOMETRY("GEO_CITY"."POINT") FROM "GEO_CITY") WHERE rn
> 0 AND rn <= 1
There are a few problems here. The first is that the `col.rsplit('.',
1)[1]` logic is too brittle to handle a column wrapped in a stored
procedure. But the greater issue is that to fix this in GeoQuery is
that I need to make `get_columns` aware if it's being called for an
outer select or the inner select, i.e., I'll have to set an alias on
the inner select while not putting any function wrapping on the outer
select. I currently don't know how to do this other than adding extra
keyword parameters in my overridden implementation that may be used by
an overridden `as_sql` used only for Oracle just for this purpose.
Needless to say, this isn't trivial -- unless there's other ideas on a
different approach I may have to drop Oracle support for GeoDjango in
1.0. I'm hesitant to be rewiring internals this close to the deadline
instead of focusing on documentation.
-Justin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
