>
> 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.
>
>
>
subCollection(Query) method is still there.
Sorry I did not look closely at the proposal, I only deprecated what it
described, and left the sort and subCollection methods in place (as it also
described). I will double check the remaining methods and update the proposal
page if you like. I am more focused on the patch right now.
> 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.
>
>
>
Agreed (for my two cents).
> 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?
>
>
>
I think it was a request for consistency, when this proposal was first written
we had just made all the feature/attribute methods have a getTypeMethod().
I think getDescriptor() is simply missing.
> 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.
>
>
>
Yep, indeed I updated he "addFeatures" example to use a ListFeatureCollection
rather than DefaultFeatureCollection yesterday.
> 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.
>
>
>
It is a good rant I understand.
My own rant was a wish that FeatureIterator (and FeatureReader) would implement
Closable.
Jody------------------------------------------------------------------------------
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
