On Wednesday 16 April 2008 18:19:32 aaime wrote: > 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.
I don't have a lot of experience with implementing datastores, although I've started to run into this just using them. I'll be sure to speak up if anything comes to me, but I think I'll need to put in some more elbow grease first. > 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. Okay, I'm also a little fuzzy on the utility of the query capabilities object (just brought it up because it was part of the IRC discussion that I noticed missing from the wiki page). If we are going to have an interface where methods may or may not be implemented isn't it more appropriate to have them throw a MethodNotSupportedException? > Cheers > Andrea ------------------------------------------------------------------------- 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
