Vitali Diatchkov wrote:
> The functionality you are talking about (methods) are from
> java.util.Collection (those methods except update()..)?
>
Indeed, and if look to the feature model branch I think update would of
even be covered.
>> That answer the question from an API perspective (is the code complete),
>> the other reason you could ask for this is from a performance
>> perspective - I would still ask that you consider using the API as it
>> stands, and spend time working on a FeatureCollection implementation
>> that acts as a cache (or buffer) of modification commands rather then
>> duck around the API and make a solution that does not scale.
>>
> I agree. But sometimes I feel constraint and conservatism that forces to
> implement workarounds and hacks that look good enough from performance point
> of view but strongly dependent on changes from the community. You implement
> local workaround, something is changed and your work is broken. I had such
> experience with TransactionStateDiff changes last spring for Shapefiles.
>
I think it is more a question of time (of people to invest in making
optimized data access), the API should of protected you
from being dependent on any TransactionStateDiff changes (perhaps I am
confused on how you were using it).
>> existing TransactionStateDiff used by Shapefile offers some of this
>> functionality, but it is not something that is under programmer control
>> (the difference between an internal cache, and an external cache).
>>
>> To sum up:
>> 1. the FeatureStore API is only there to be optimized into SQL, it is
>> not intended to be complete. For add hoc modification FeatureWriter and
>> FeatureCollection are both available
>> 2. I am trying to move us to use optimized FeatureCollection
>> implementations
>> 3. making a FeatureCollection that is aware of Transaction state changes
>> (and feature modification events) will accomplish your goal within the
>> bounds of the existing API.
>> 4. staying within the bounds of the existing API will allow your code to
>> scale transparently to large data sizes.
>>
> So, the summary is: FeatureCollection should be considered to be extended to
> provide rich functionality of ADD/NODIFY/REMOVE operations over features?
>
Correct, that is the way things are set up, and the reason I have not
implemented the idea you suggested.
If you want to look into a "check-out/check-in" idea - I am not against
it. I just ask that the result of a "checkout" be a feature collection.
So the code you write for analysis can still be used for large scale work.
Cheers
Jody
>> A simpler API can be used to process features in place, the idea being
>> that you can construct a "chain" of operations and have a fun time.
>>
>>
> I see Operation API over basic functionality with basic operations like
> ADD/MODIFY/REMOVE for features. FeatureStore, FeatureCollection, whatever
> like this provides basic functionality to work with external data store on
> the low-level, depending on the data store nature, but Operations API is on
> the top level for implementing of "business process" operations.
>
Thinking through that, remember the Operations API I listed was a
"proposal", I think the end result would be better made around
FeatureCollections (as a whole) - rather then process Feature by
Feature. But yes people would love a high level "analysis" pack called
"Operations" - and they have taken a couple runs at it. So far the only
useful thing is in uDig.
>> I am not against the idea of Operations, we use it in uDig to great
>> effect, but I am starting to think something at the FeatureCollection
>> level will be of more use, especially now that FeatureVisitor is defined
>> and used to great effect for aggregate functions showing the way to back
>> some operations into raw SQL while not breaking ObjectOriented
>> encapsulation.
>>
>> Jody
>> Cheers,
>> Jody
>>
>>
>> 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&kid0709&bid&3057&dat1642
>>> _______________________________________________
>>> Geotools-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> 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&kid0709&bid&3057&dat1642
>> _______________________________________________
>> Geotools-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
>
> P.S. I will write couple of "fun" questions later, need time to think out..
>
>
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
