GeoQuerySet extent() method fails to limit

[billtown@…]

I have an object with geometry points.

I expected to be able to return 100 objects' extent using a limit. However as demonstrated below the limit is never in the raw sql query:

>>> test = SamAddress.objects.all()[:100].extent()
>>> print test;
(-84.390510000000006, 33.754629999999999, -77.678370000000001, 40.513269999999999)

>>> test = SamAddress.objects.all().extent()
>>> print test;
(-84.390510000000006, 33.754629999999999, -77.678370000000001, 40.513269999999999)

Debug from postgres.....

2011-01-16 18:45:04 EST LOG:  statement: SELECT ST_Extent("world_samaddress"."geometry") AS "geoagg" FROM "world_samaddress"

2011-01-16 18:45:13 EST LOG:  statement: SELECT ST_Extent("world_samaddress"."geometry") AS "geoagg" FROM "world_samaddress"

This actually makes sense since ST_Extent is indeed an aggregate function and cannot be limited (similar to count() or sum()).

I am running geodjango 1.2.3.

Version 1.3 alpha 1 SVN-14993 is different in that it does pass through the limits looking like this...

Debug from postgres

2011-01-16 17:39:10 EST LOG:  statement: SELECT ST_Extent("world_samaddress"."geometry") AS "geoagg" FROM "world_samaddress limit 100"

I don't know why my version does not use the limits on extent() and or count().
However the return value would still be the aggregate and not the limited results.

select ST_Extent(geometry) from world_samaddress limit 1;

BOX(-84.39051 33.75463,-77.67837 40.51327)

select ST_Extent(geometry) from world_samaddress;

BOX(-84.39051 33.75463,-77.67837 40.51327)

The same would go for count() (or any aggregate function?

In future versions if a subselect were used it would do what I wanted it to do (which is odd) but return the extent of 100 points.

 select ST_Extent(geometry) from (select geometry from world_samaddress limit 1) as foo;

 BOX(-84.39051 33.75463,-84.39051 33.75463)

 select ST_Extent(geometry) from (select geometry from world_samaddress) as foo;
 
 BOX(-84.39051 33.75463,-77.67837 40.51327)

[jbronn]

Cleaned up ticket formatting.

[Russell Keith-Magee]

Accepting on the basis that jbronn has seen it, and didn't reject it out of hand.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Reinout van Rees]

As you say, it isn' just an extent() problem, but also sum() and count().

Turns out, there is a ticket for the generic case of aggregates not working with limits: #12886

It is fixed in ​https://github.com/django/django/commit/7737305a4f5dc5006d92dac3a61523ad6c2a523a, you'll see some "force_subquery" lines in there, which matches your comment of "In future versions if a subselect were used..."

Extra note: the fix is in 1.7 and higher.

[Sander Smits]

I made a pull request that demonstrates that this indeed has been fixed. It can be found here: ​https://github.com/django/django/pull/3532

[Simon Charette]

Looks like this hasn't been fixed on Spatialite and Oracle.

[Claude Paroz <claude@…>]

In 374c2419e5adef53a643bf69c4753a6bf0c78a98:

Tested that geo aggregates support slicing

Refs #15101. Patch slightly reworked by Claude Paroz.