> Hi, > here is my feedback. > > FeatureAccess name must be killed, it's too easy to mistake it as part > of the FeatureSource, FeatureSource, FeatureLocking familiy. > ComplexDataStore may not sound nice, but it's at least consistent > with the other names you're coming up with. right. A couple options, more would be appreciated: - FeatureDataStore - Store - FeatureData - DataRepository/FeatureRepository (may apply: http://en.wikipedia.org/wiki/Repository) > > ComplexFeatureStore misses modifyFeatures. We need at least the version > that takes the list of attributes and the list of values. Rationale: > we have remove(filter) which is the equivalent of "delete ... " on > dbms. Where is the equivalent of "update ..."? Are we giving up on > efficient mass feature updates? I understand, though its not that simple for plain Feature. We'll need to get rid of the flat table concept about Feature and think of it as a full featured object. Update could be handled more like an O/R mapper does. That is, update(FeatureCollection) where the contents are required to have propper fids? Also for a single attribute mass update and xpath expression and a namespace context would be needed. With complex features some complexity is added, true. That's why I would stick to cursor based update for the short term, letting modifyFeatures(AttributeDescriptor[], Object[], Filter) as it is for the simplefeature case in FeatureStore. A full fledged solution towards optimized bulk update for complex features seems too much for this run. I'd rather start simple and evolve when there's a better picture of the implicancies?
> While we're at it, it would not be bad to have the method look > like modifyAttributes(AttributeDesciptor[], Expression[], filter) so > that updates like "update blah set price = price * 2" could be encoded... > But I'm digressing, it's probably more pain than we want to take? Sounds good, note taken for when the time comes :) > > ComplexFeatureLocking: can we get rid of the lockFeatures(Query), > unlockFeatuers(Query) methods? What are they good for? We do lock > features, not attributes. (Am I missing something?) Fine for me. It seems overhead on the original FeatureLocking too, at least someone is using it to reproject filter geometries with the query CRS.. dunno. In any case I'm fine for getting rid of it and start as simple as possible, > > The ResourceCollection part does not make sense... you > say collection is not a feature and then the code example > states it's a simple feature? Moreover, why is it still > extending ResourceCollection? ah, I should of make the example clearer. The "after" example shows geotools FeatureCollection as it is right now, plus extending geoapi FeatureCollection. So current API keeps backwards compatible, but FeatureAccess can work on plain geoapi FeatureCollection. That's the one that does not extend Collection nor is a Feature. Makes sense? gonna update the example, thanks for pointing it. > > As for the no interfaces/generify debate, my generics abilities > are probably lower than yours. Can anyone come up with a counter > proposal using the hybrid approach so that we can have a look > at it instead of talking about vapourware? gonna try to figure it out in real code then come back with my findings. Cheers, Gabriel > > Cheers > Andrea > > !DSPAM:4045,47aacc9c79531961014482! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
