On 4/14/11 10:51 AM, Tim Schaub wrote: > On 4/14/11 12:29 AM, Andrea Aime wrote: >> On Thu, Apr 14, 2011 at 2:20 AM, Tim Schaub<[email protected]> wrote: >>> WFS 2.0 describes both paging with and without transactional >>> consistency. It's not a requirement to be consistent there even >>> (PagingIsTransactionSafe can be true or false), right? >>> >>>> Also it seems that WMS GetMap already supports paging... and this is >>>> more or less following suite what it is doing. >>>> >>>> >>>> Also curious about sorting... I remember something like sorting by >>>> default >>>> on the feature id while paging, but my memories of it are foggy, we >>>> discussed >>>> this with Gabriel a loong time ago (when the paging machinery was >>>> added to >>>> GeoTools). >>>> >>>> >>>> As I understand things how they are implemented now using startIndex >>>> requires the underlying datastore to be able to do sorting. And when >>>> the >>>> client does not specify an explicit attribute to sort on this means >>>> doing a natural sort (feature id). If you look at >>>> ContentFeatureSource.getReader(Query) you will see a check there. >>>> >>>> Which more or less means that paging can only be used with jdbc >>>> datastores. Which personally I think is fine since they are the only >>>> ones that can really do it efficiently. Thoughts on that? >>> >>> Would it be possible (later) to do sorting for all stores? I understand >>> it would be inefficient, but it's a bigger drawback (in my opinion) to >>> have a feature be store specific. As the client has no way to know >>> about these distinctions. >> > > Sorry, I meant to ask about *paging* on all stores.
And I should add, I know it is less efficient for the server to do paging for stores that don't support it. But in my mind, paging is about easing the burden on the client. A response set with a ton of records may be a lot for the server to handle, but resources are typically more limited on the client. Paging manually would only add minor work on the server (as I imagine it), but it is a huge relief in terms of the burden on the client. > >> A trivial way to implement sorting is to do it in memory. The day someone >> decides to sort on that 2GB shapefile boom! >> We'd need a secondary storage sort approach (mergesort), writing one >> would >> require quite a bit of time and the assurance everything in the >> feature is >> serializable. >> Another approach would be to have a hsql db, dump everything in it, and >> make it do the sort. >> >> In both cases it is to be noted that we first have to sort the large >> collection >> and then extract the page of data we need, so in the case of the large >> shapefile >> you'd have to first sort everything in order to get your 50 records page. >> Not efficient... (a db could do that efficiently only if it has a >> index on the sorting >> column, something that is normally available for the primary key) >> >> Cheers >> Andrea >> > > -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
