On Sun, Dec 11, 2011 at 6:50 PM, Justin Deoliveira <jdeol...@opengeo.org>wrote:
> After the fact I've noticed that on trunk a similar approach was taken,
>> but
>> only to support offset without caring for sorting. I thought we wanted to
>> have paging
>> only when stabilized by a sort, am I mistaken?
>> In my patch when a start offset has been specified natural sorting is
>> imposed
>> even if not asked directly.
>>
>
> We went around on this a few times but it was thought that it would be
> more desirable to simply do the offset regardless of whether the underlying
> format could sort, rather than throw an exception back. Accepting the fact
> that using a non sorting store will lead to inconsistent results. This also
> seemed to fit with how we handle transactions... allowing them on stores
> that can actually can't really do transactions, rather than throwing an
> exception back. Not a perfect analogy I know. But the fact that the
> mergesort feature stuff was coming down the pipe and we would eventually be
> able to supplement the non sorting stores regardless it seemed acceptable.
>
I see. However with the patch I've made we can basically add sorting
support where
none is found.
There are two sides indeed:
a) add sorting support for all, regardless of the native support
b) force natural sorting during paging when no other sorting is around
a) seems to be nice in general, along with the lines that WFS hides whatever
capabilities the actual underlying data storage has.
b) is doable, but takes a toll on paging if the native store does not
support
natural sorting
At the very least I'd like to support a), b) I don't really have an opinion
on.
>
>> Anyways, a bit more work seems to be needed in order to harmonize the
>> two branches but things appear to be looking good.
>>
>> I've attached the two updated patches on the jira, look for the AA suffix:
>> http://jira.codehaus.org/browse/GEOS-4485
>>
>
> Looked over the patches and they look good to me. Do we have a handle on
> the issues merging with trunk?
>
Afaik there is not much to merge on trunk, besides that
GeoServerFeatureCollection.
If we go for just supporting a) I guess I could still
use GeoServerFeatureCollection,
just making sure it simply does skip and max, or roll a new
SortinFeatureCollection
that only does sorting and keep MaxFeatureCollection (which would have to be
back-ported to 2.1.x).
Regarless the paging tests would be exactly the same as on trunk.
I did not touch much else on the original patch, do you know if there are
other
significant differences?
Like, in the bindings for example?
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
