Andrea Aime wrote: > Jody Garnett ha scritto: >> Good discussion Andrea, I am sorry I cannot give this my full attention. Still a good discussion. > You're not understanding me. All the example you pointed me at show > the same sins as our FeatureCollection. In 4 years of Hibernate I've > never used their iteration/scroll support. I think I am understanding you, I just have a different focus then you.
From my perspective as long as you are programming against readers and writers, and not something like FeatureCollection I cannot set you up to be optimized. FeatureStore right now has methods (such as addFeatures) to do "bulk" operations, these are the same methods that GeoServer uses - and represent the best "optimization" we got. I would like to see this as a single discrete object: with the list I made above (FeatureType, Features, Summary) boiled down to a single class. > I'm not questioning the details, I'm questioning the design. With respect to the specifics of "are we a Collection" we got a couple points against: - Collection does not seem to fit on a mathematical level (is this true?) - Iterator hides the possibility for exceptions (this seems to be your major concern?) - unclear how to either fail early, or fail late (probably as a consequence of the above) We also have a benefit: - accessible to new users I agree with these concerns, and the benefit, but they are details that do not effect my design one way or the other. > Even with all details right, it would not be a success to me, because > it just tries to hide reality, and I prefer to see things as they are. So perhaps we should decide how reality should be presented. I cannot make do with the amount of exceptions thrown in the typical case of FeatureReader; if we allowed invalid data (or incomplete data) a lot of this problem would go away. Rather then throwing a hard exception we can provide a object on each iteration, and only throw with a hard IOError when an actual IOError (or SQLError) has occurred. It also sounds like a for loop would do everyone some good with respect to being easy to understand/use, even if it means adding a close method to feature collection. Andrea do you have any suggestions on how reality and ease of use can be balanced; FeatureReader really does not appear in the GeoAPI FeatureCollection so it is not going to be around for you to fall back on. It does support invalid data so some of the pain is taken away. Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
