Gabriel Roldán ha scritto: >> 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)
Anything that's not matched by the Feature.+ regular expression is welcomed. >> 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? I strongly disagree here, we're talking about interfaces, not abstract classes. With abstract classes you can assume you'll add methods without much pain for the implementors and users, with interfaces it's different. A stuff based on a collection of feature and fids would not be up to the task of carrying the the simple sql content: update x set att = 1 where att2 > 10 If you follow O/R mappers, then you want bulk updates, Hibernate was despised a lot exactly because it missed bulk update and deletes, see the current syntax. Lately it has been added: http://www.hibernate.org/hib_docs/reference/en/html/batch.html As for the optimization topic, I did not mean to make things optimized from day one. You can start with a feature store that does everything in memory like a user could do, and allow subclasses to do the optimized thing when it's possible... that's just what the current AbstractFeatureStore and PostgisFeatureStore are doing todays, the first provides generic support based on iteration, the latter optimizes it out favouring bulk updates when the filter is encodable. Now, I'm not a pro with with complex features, but given a set of paths locating an attribute and a literal it should be possible (and easy) to implement the generic, non optimized code path, even when using expressions (you pass the original feature into all the expressions, collect results, and then set all of them back into the feature, write down to the storage). >> 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, Ah dammit, you're right, I forgot about reprojection. Eh, it depends on how the crs is managed. I mean, if the geometric filters do have the crs embedded in the geometry literal the we can do it, otherwise not. There is that convention of putting the crs as the user data of the JTS geometry, but it's just a convention, it's not even documented as far as I know... In fact, the crs fields in query are meant to be used for the result, one to force the crs of the result, the other to reproject the resulting geometries, but they have nothing to do with the filter itself (or not? that's what I remember?). >> 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. Hum, not sure, but I'll look at the updated example all right :) >> 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. Thank you Cheers Andrea ------------------------------------------------------------------------- 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
