Re: [Geotools-devel] [Geoserver-devel] Some concerns on FeatureStore.addFeatures()

[Andrea A. <aa...@op...>]

Jody Garnett ha scritto:
> You are correct - the whole adding Features and assigning Fids workflow 
> is messed up. See GeoAPI for a more realistic workflow that we have not 
> had time to implement. Basically we should not return the "Set" until 
> *commit* is called (since some added features may be removed by later 
> operations in the transaction).

I disagree on this approach, we're selling away the convenience for the 
most mainstream system (databases) just to handle the issue with two
other datastores. I would feel more comfortable having both, returing
fids right away if possible, and return all of them again at the
end of the transaction. In both cases, do preserve the insertion order,
since this is what the WFS spec requires us.

> When I last looked poor GeoServer was adding Features one at a time in 
> order to verify that it was successful - hense the ability to report 
> things in order :-( I may be getting confused with the update process 
> however.

Yup, update does change a feature at a time.

> We could change this to be a SortedSet - with the order being determined 
> by insertion order. Or simply a unmodifiable List.

SortedSet handle Comparables, or stuff that has a comparator anyways.
Insertion order is not an attribute of the FIDs, we can work around this
by inserting a larger bean that has insertion order too, but that would
mean playing with our non standard implementation of a SortedSet.
List is the most natural choice.

As usual, I'm not only concerned with the medium term issues, but also
about what's happening now. And what's happening now is that we're not
complaint with WFS spec _today_. The easiest fix I can think of is going
into the 2-3 places that are filling up HashSet instances with FIDS and
use a LinkedHashSet instead, and then go and modify the javadoc of
addFeatures stating that the Set returned must have an iteration order
equals to the insertion one. Anything against that?

> Basically we ran out of enthusiasm on this issue (everyone was stick of 
> talking about it on email).

The real issue is that changing this would require changing the 
datastore interface. Can we setup a wiki page with a list of changes
we deem important for the datastore API, and maybe have a voting section
behind each one, so that we can also gather a PMC opinion as a whole
on each one?
In the near future complex features will hit us, if we have to break
the API, let's do it once.

Cheers
Andrea