2015-09-10 23:13 GMT+02:00 Jody Garnett <[email protected]>:
> Since its not an "Ordered" DataStore that should preserve order I'd
>> suggest to remove these tests. Opinions?
>>
>
> If you change the functionality, change the test to match. There should
> now be several feature collection implementations to choose from so code
> that requires a TreeSet based functionality has a migration path.
>
Not sure about I understood you correctly. Do users of MemoryDataStore
expect to get the features the same order they wrote it before? I thought
writers/readers have to provide a Query, if there is no order criteria in
it's kind of unpredictable what order the result is. I would compare it to
a database, its kind of internally implementation details (see
http://stackoverflow.com/questions/899514/default-row-ordering-for-select-query-in-oracle/900106#900106
).
Oh, now I read the following comment :
https://github.com/fgdrf/geotools/blob/0ca687939b17ccb34d3dbbb8df4c838d9d02e86f/modules/library/data/src/main/java/org/geotools/data/memory/MemoryDataStore.java#L131
and wondering even more ;) that the whole rendering system depends on
internal behaviors. I understand the requirement but at the moment not
really the place of implementation to match it. I guessed the renderer
should take care of, if required (Is there a hint/flag for it?)
>
> I'm wondering how you would think about this "proposal". However, STRtree
>> internal creates a new List every type the Index is requested. I haven't
>> investigated thread savety of STRtree yet. Maybe anybody of you has much
>> more experiance than me to give feedback on that
>>
>
> The index needs to get rebuilt each time a feature is modified, so other
> than that overhead (which could be pushed off until "commit" ) it should be
> workable. The List should not be a problem, as it offers you a bit of
> independence (at the cost of possibly traversing through out of date
> information).
>
> Possible workaround is to store feature id in the STRtree, and then look
> up current feature value by feature id. This however makes me wish for a
> graph database.
>
Actually, I used a modified MemoryDataStore for years to work with features
from 0 to 20000 per featureType and never hat problems accessing/quering
features from ConcurrentHashMap. However, optimizing performance I would
move to a later point of time sind the current Implementation is at it is
fast enough. In addition Concurrent classes act the same "temporary out of
date informations"
Interesting discussion, thanks for your feedback :D
--
> Jody
>
-- Frank
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
