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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to