How about a previous proposal:
-
http://docs.codehaus.org/display/GEOTOOLS/Focus+FeatureSource+around+FeatureReader+and+FeatureWriter
Some of the substance of this proposal was done at the last moment by me prior
to the release of GeoTools 2.5.x - the part protecting us from Java 5
Collections.
See:
for( Feature feature : featureCollection ){
// do stuff
}
featureCollection.purge(); // clean up any outstanding iterators
HISTORY
In GeoTools 2.0 FeaureCollection was in memory. In GeoTools 2.1 it was
rewritten to to be "streaming" (along with the DataStore api):
- http://docs.codehaus.org/display/GEOTOOLS/2.1.x
I then had a user revolt on my hands - and was too new to stand my ground:
- http://docs.codehaus.org/display/GEOTOOLS/Bring+Back+FeatureCollection
To make the users at the time happy we made our FeatureCollection a Java
Collection; so they could get back to work without there code being broken.
When we decided to migrate to Java 5 we *had* to break being a Java Collection;
because the new syntax would ensure that our feature iterators were never
cleaned up.
The thing is FeatureSource and FeatureCollection kind of do the same thing (now
that we no longer support Java 5 Collection).
I kind of view the FeatureCollection as a prepared statement - only good for
getting an iterator from at a later date. I know it provides a few things like
the schema and the bounds .. but that still kind of feels like a prepared
"query" from which we can issue a query to get bounds, or a query to get the
schema or a query to get the iterator over the contents.
Jody
On 26/05/2010, at 1:55 PM, Michael Bedward wrote:
> HI Jody,
>
> +1 for removing the useless listeners
>
> I don't think I understand the wider issues though. Can you point me
> to some previous posts that I should look at ?
>
> Michael
------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
