On Thu, Jun 21, 2012 at 3:09 AM, Jody Garnett <jody.garn...@gmail.com>wrote:
> A very old proposal removing the methods that assume an in memory model:
> - http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+revolution
>
> I have a small non-destructive patch providing the remaining deprecations
> outlined in the proposal:
> - https://jira.codehaus.org/browse/GEOT-4181
>
> Can I ask for a review as I would like to apply this change prior to 8.0.x
> rolling out in order to respect our deprecation cycle.
>
Ugh, implemented as you suggest it will affect performance of WPS chaining
a lot.
This is due to the removal of the subCollection methods, which are the only
way to have a streaming process
(one that returns a computing collection) compute less data if a downstream
process needs less.
This approach is not used much now, but killing it right away will make it
impossible to setup
process chaing that efficiently work in pull mode.
If at all, what I'm realy missing there is a subCollection(Query) method
that would replace subCollection(Filter) and
subCollection(SortBy).
Generally speaking asking users to use FeatureSource.getFeatures(Query) is
a bad move, not because it's
wrong per se, but because you might have long lost any reference to the
feature source.
I'm confused by getType and getDescriptor in the patch
(https://jira.codehaus.org/secure/attachment/60308/geot-3181.patch)
Read about it in the proposal, but still does not make sense to me... why
should we go
and replace getSchema with getType, it seems to do most harm than good?
The rest about removing all the modification oriented methods from feature
collection seems
reasonable to me, I always think about feature collections in terms of
something that is
a "view" of a store. Real in memory collections can offer modification
methods of course,
and we should update demo and tutorial code accordingly.
One thing that still bothers me a lot about current collections is that
they never throw a IOException,
this is still a vestigial decision from the "collection is a memory thing"
times, and makes it harder
to write an implementation that actually does I/O ("ouch, this code does IO
but I cannot declare
these IO exceptions...").
I understand changing this would break a lot of client code, just ranting
here.
Cheers
Andrea
--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
