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 -~----------~----~----~----~------~----~------~--~---