Consider that this issue was not found by test cases, or cite tests even I
assume you will be pretty well in the clear.
Can you or your team patch for wednesday? I am onto windows installer
tomorrow.
--
Jody Garnett
On 20 March 2017 at 22:19, Dave Blasby <dbla...@boundlessgeo.com> wrote:
> Hi, Jody,
>
> I also refactored code using DefaultFeatureCollection to use
> ListFeatureCollection - so I expect this is a quick patch (wasn't sure if
> it would cause issues). I will look at the test cases...
>
> Thanks,
> Dave
>
> On Mon, Mar 20, 2017 at 10:02 PM, Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Interesting, DefaultFeatureCollection has always used a TreeSet (to
>> support fast fid lookup since I figured that was important when initially
>> designing feature collection, my mistake).
>>
>> There is a quick fix we could try using a ListFeatureCollection in this
>> section of code, care must be taken to avoid duplicate Fids since it is
>> only a wrapper.
>>
>> *ArrayList<SimpleFeature> list = new ArrayList<SimpleFeature>();*
>> *list.add( SimpleFeatureBuilder.build( TYPE, new Object[]{
>> wkt.read("POINT(1,2)"), "name1"}, null) );*
>> *list.add( SimpleFeatureBuilder.build( TYPE, new Object[]{
>> wkt.read("POINT(4,4)"), "name2"}, null) );*
>>
>>
>> SimpleFeatureCollection collection = new ListFeatureCollection(TYPE,lis
>> t);
>>
>> For more background/code examples see docs
>> <http://docs.geotools.org/latest/userguide/library/main/collection.html#performance-options>
>> .
>>
>> --
>> Jody Garnett
>>
>> On 20 March 2017 at 21:45, Dave Blasby <dbla...@boundlessgeo.com> wrote:
>>
>>> Hi,
>>>
>>> I was looking at the WFS-T response for Inserts (it's a list of FIDs).
>>> The spec says these should be in the same order as the features in the
>>> request's Insert elements.
>>>
>>> However, I'm seeing these in a "strange" order. I think I've tracked it
>>> down to the DefaultFeatureCollection implementation. This stores the
>>> features in a SortedMap<String, SimpleFeature>, and the iterator just
>>> returns them in the text-natural-id-order (ie. "new0", "new1", "new11",
>>> "new2", "new3",... -- "new11" is in the wrong order). This messes up the
>>> order of the new fids for the inserted features.
>>>
>>> Here's it using the DefaultFeatureCollection;
>>> https://github.com/geoserver/geoserver/blob/2.9.x/src/wfs/sr
>>> c/main/java/org/geoserver/wfs/InsertElementHandler.java#L98
>>>
>>> and the passing it (incorrectly ordered) off to the underlying datastore;
>>> https://github.com/geoserver/geoserver/blob/2.9.x/src/wfs/sr
>>> c/main/java/org/geoserver/wfs/InsertElementHandler.java#L189
>>>
>>> Here's the DefaultFeatureCollection implementation;
>>> https://github.com/geotools/geotools/blob/master/modules/lib
>>> rary/main/src/main/java/org/geotools/feature/DefaultFeatureC
>>> ollection.java#L330
>>>
>>> I'm surprised that no one's seen this and there aren't any test cases
>>> for it - am I seeing things?
>>>
>>> Aside - does anyone know how to have WFS-NG preserve FIDs for inserts?
>>> I havent been able to figure out how set it to use idgen=UseExisting
>>> instead of idgen=GenerateNew?
>>>
>>> Thanks,
>>> Dave
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
