David Winslow-3 wrote: > > There was talk of having a dumb implementation of paging available that > individual datastores could overwrite with more efficient implementations. > I > see no mention of this in the writeup, so has that idea been dropped or is > it > just considered to be implicit? >
This was my point of view as well, up to the moment when I actually started to write down the proposal. In that moment I realized that sorting and paging must be there at the same time, and not only that, but you really need sorting on the fid too to make things work. Say you sort on an attribute that's not the fid, the order of the features that have the same attribute value is undefined, which is based paging wise. So... you always have to add a extra sorting clause on @gmlid no matter what. Now, which datastores do support sorting nowadays? Only JDBC based ones. Which ones do support sorting on @gmlid? NONE! Long story short, we are already coming from a situation where datastores are not abiding to the Query contract, and we don't have the workforce to fix them all... so I guess we have to surrender and accept the fact certain things may not be supported, even if this means that writing a client needing those features against datastore is going to become a real pain. If you have suggestions on this one, I'm all ears... I don't like this situation either. Aside... how one does implement the damned paging if sorting on feature id is not implemented? Simple and... horrible: make a query that returns only one attribute of the feature (since generally speaking you cannot ask only fids to be returned... ), store all the fids in memory, sort it, and then make a big bad query listing all of the fids in the requested page (and hope this does not require encoding in sql 10.000 fids...). Ok, this is going to work only on very very small dataset but... what can I do? David Winslow-3 wrote: > > Relatedly, perhaps FeatureSource.getQueryCapabilities() should be split > into > two: FeatureSource.getAvailableQueryCapabilities() and > FeatureSource.getNativeQueryCapabilities() , to indicate all supported > capabilities and all optimized capabilities, respectively. Although, I > suppose the former would be unnecessary if default implementations of all > operations were provided. > Hmm... I'd prefer to have a single object with very few properties. The filter capabilities thing is something that I added becaues Jody asked for it, but I'm not really certain what's the usefullness of it (Jody, can you elaborate)? What I'm really interested in is what the datastore can do, not what it can do fast. Cheers Andrea -- View this message in context: http://www.nabble.com/Feature-paging-proposal-created%2C-please-discuss-tp16730161p16734848.html Sent from the geotools-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
