Hi,
moving on on this, I tried the following approach:
- created a new LimitingVisitor interface with getStartIndex and
getMaxFeatures methods, to be used by visitor aware stores
- changed UniqueVisitor to implement this interface and added pagination
capabilities to the visitor if those two properties are defined (this will
handle stores that are not visitor aware)
- made JDBCDataStore aware of LimitingVisitor, using it to get limits in
aggregated queries, if limits are defined in Visitor instead that in Query
This way, the old behaviour is mantained if limits are defined in Query,
the new one (limits applied after aggregation) if they are defined in the
visitor.
What do you think?
Can I move forward with it?
Mauro
2014-05-19 17:32 GMT+02:00 Andrea Aime <[email protected]>:
> On Mon, May 19, 2014 at 5:16 PM, Mauro Bartolomeoli <
> [email protected]> wrote:
>
>> Hi,
>> recently we tried to implement a WPS process to do paginated extraction
>> of sorted unique attribute values from features.
>>
>> The approach was to apply a UniqueVisitor to a Query object with sortBy
>> and limits applied.
>> The problem with this approach is that the current semantic for such
>> implementation is:
>> - first apply the sort and limits
>> - then apply the visitor (in this case unique)
>>
>>
>> This is not the desired behaviour for us, we would need:
>> - first apply the sort and unique
>> - then apply the limits
>>
>> Now my question is: is the current behaviour the desired semantic, or
>> just a constraint of the aggregation by visitor implementation for which
>> the visitor needs to be applied only after feature fetching has happened
>> (apart from cases like JDBC where the visitor can be implemented directly
>> on the database)?
>>
>> Just to decide if we need to reimplement the process or we can try to
>> change the Geotools semantic.
>>
>
> Hmm... interesting question.
> In terms of API, we have a collection, that has a certain content defined
> by the Query object.
> And then we have a Visitor, that can visit the contents of the collection,
> and it's completely
> unaware of the Query.
>
> Stores can decided to avoid doing the full scan of the collection, and
> optimized out the
> visitor some way, like the JDBCDataStore does, but they have to do so that
> the results
> are the same as if the visit happened in memory.
>
> Given this, I don't think it's possible to change the way the store works
> now, nor change
> the Visitor semantic, because to do so, we'd need to provide the visitor
> with the Query object,
> so that in memory visits can take into account sort and paging.
>
> That said, I see how the current behavior is not desirable for extracting
> a large number of
> unique values, and you're not the first to have issues with it, there was
> a recent thread
> with the very same issue reported.
>
> I'm wondering if the way to go would be to add a SortBy[] and a
> start/limit to the UniqueVisitor,
> to specify how the results should be paged, implement memory support for
> them for all
> stores to use, and then have JDBCDataStore consider those when encoding
> the visitor
> into a SQL query
>
> Cheers
> Andrea
>
> --
> ==
> Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
> for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
--
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
