Hi Justin,

Sorry, I should have run the gis tests as well.  (Is that Malcom
snickering I hear?  I'm chastened.)

Did GeoDjango break in r8426 then, as Oracle in general did?  That's
where extra_select changed.  I can see how our new code in r8445
breaks on your function column.

I'll look at it today and see if I can come up with a fix.

Matt

On Aug 20, 10:27 am, Justin Bronn <[EMAIL PROTECTED]> wrote:
> > 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to