Re: [Geotools-devel] FeatureStore limitations

[Chris H. <ch...@op...>]

I don't know that there were good reasons to restrict it, except that 
when we coded it we only had one use case - WFS-T update.  So we coded 
against our requirement with the thought that it could be refactored at 
a later date if improvement was needed.  As long as we keep the original 
API around at least for awhile I'm fine with a new interface as well. 
Ideal with the one just built on top of the other but also allowing 
expansion.  So I'd so go ahead and make a proposal, ideally interface, a 
default implementation, and an abstract implementation that can slot in 
by default to the existing datastores.

best regards,

Chris

Vitali Diatchkov wrote:
> 
> FeatureStore interface form some point is quite narrow. Try to explain use
> case.
> 
> Modifications are restricted by set of methods like:
> 
> 	modifyFeatures(AttributeType[] type, Object[] value, Filter filter)
> 
> This does not give enough flexibility to work with "detached" set of
> features (I use "Hibernate"'s term thinking it is good enough to
> characterize that behavior) - features that were requested from DataStore
> and put into the memory for some processing, whatever. Quite complex
> processing may be performed over them, various attributes  may be modified,
> etc (except FIDs of course - they are kind of non-modifiable entities - keys
> - by which the "detached" set can be bound ("attached") again to the
> external data store later.
> So I would like to request set of features, "detach" them from data store,
> perform arbitrary modifications, then update. I would like to have the
> functionality in FeatureStore to pass a collection of "detached" features
> (through any collection interface for features, abstractly now) to update
> them.
> 
> Now I am restricted by modifyFeatures(..) method that I have to call
> multiple times. The problem here that there is no way to perform batch
> updating of features that improve performance of this use case
> significantly. (Just take a JDBC case  to imagine). Each feature has a FID,
> we have FIDMapper in JDBC case, so always we can reconstruct connection
> between feature in external data store and feature in "detached" set - don't
> see a problem here.
> 
> What current implementation of FeatureStore. modifyFeatures(..) gives to us?
> It lets to just specify filter to request features to be updated and specify
> what attribute types and its values to update. A kind of batching update in
> case when the set of features must be updated by the same attribute values.
> But what if I have just various features has been requested on different
> stages of my business process, in each feature I modified various attribute
> values , etc. I want a method to pass a collection of features, their IDs
> are native, so we can reconstruct a connection with features in external
> data store. In JDBC case , for example, we can prepare UPDATE statement and
> perform updating of all features one by one with one prepared statement,
> etc.
> 
> Most likely I see just one side and there are other points and reasons to
> have so restricted modifyFeatures(..) capabilities. From described use case
> point of view, not so much opportunities for various optimizations of
> updating with this design.
> 
> But I would like to discuss that issue:)
> 
> Regards, Vitali Diatchkov.
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Geotools-devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 
> !DSPAM:1003,44f586f4263241702038478!
> 

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org