[Geotools-devel] 2.5.x branch - Id mutable or just unassigned?

[Jody G. <jga...@re...>]

Gabriel Roldán wrote:
> Hi Jody,
>
> my understanding from yesterday's meeting was that we needed to branch 2.5.x 
> in order to not hold back other projects, but no release were needed so 2.5.x 
> becoming a development branch means we can tackle those pending issues after 
> the branch is created. Is this possible at all?
>   
Since it involves an API change I would rather to this right now if you 
are available Gabriel.
Jody
> what bothers me is the three way communication path to get at the generated 
> feature ids:
> - if in auto commit, catch an event per feature to get the id
> - if in transaction, catch the event for the whole transaction with the set of 
> ids
> - either way, addFeatures() returns the set of ids
>   
That is why I want to return a List<FeatureIds> so we can have one 
workflow that does not depend on events for the geoserver case.
1. Make a List<FeatureIds>
2. As you do each insert operation add to your list of FeatureIds (the 
insert operation will return a List<FeatureId> so you can do this)
3. Call commit (if you are not in AUTO_COMMIT mode)
4. Return the list of FetureIds
> Yet the need for it is recognized to be the inability to generally get to the actual id before commit.
> So imho of the options you worte about the one I feel better with is:
>   
Right I think we are all in agreement here.
> but still the FeatureId changing under your feet (it is an immutable interface) leaves me a bit uncomfortable.
>   
I view this as reflecting reality; the FeatureId is basically 
"unassigned" until the commit is done.
> Would it be too crazy for a FeatureEvent of type COMMIT to hold a Map<FeatureId, FeatureId> mapping the pre-commit (and hence volatile) ids to the persisted ones so there's no magic going on?
>   
I think that may be a little crazy; but it is a crazy problem. As it 
stands now BatchEvent holds a Map<String,FeatureId> so it can assign the 
correct FeatureIds during the commit. The thing I like about returning 
"unassigned" FeatureIds is that the GeoServer code becomes simple and 
straight forward.

I will jump on IRC and we can plan the day.
Jody