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

Reply via email to