Re: [Geotools-gt2-users] Retrieving FIDs on WFS inserts

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

zze-M2S FRISON V ext RD-BIZZ-SOP ha scritto:
> Nobody has an answer to my 2 questions?

Guess not :(
Ok, I'm not the wfs datastore mantainer, but I can have a quick
look at the code.

> 1) Why featureStore.addFeatures() is returning wrong FIDs (ie. not the 
> ones which are based on the DB sequence and are really used at the 
> end into the DB) ?

Hum, I think you're onto something here.
WFSFeatureStore.addFeatures() behaves in a peculiar way if
you're inside a transaction: it clones the feature you've passed,
and returns a set of random fids, without really hitting the
WFS server.
The server is hit when you commit the transaction, and after that
you can get the correct fids by using

WFSTransactionState ts = (WFSTransactionState) 
Transaction.getState(myWfsDataStoreReference)
String[] fids = ts.getFids(typeName)

This should give you both ordering and the the right fids.
Yet, I'm not sure, because I've never used the WFS data store and
I'm looking at its code for the first time.
This behaviour is required to ensure the proper transaction semantics,
that is, all the calls to the server have to be performed on transaction
commit, otherwise it's not more a single transaction, but a set of
separate transactions, and you lose atomicity.

If you're using an auto_commit transaction instead, addFeatures()
will hit the server right away, and return you the right set of fids, 
but without ordering.

If I'm right with my analysis, I think the documentation here should be 
changed and warn people to ignore the returned fids, and how to gather
the good ones when the transaction is committed.
Moreover, in case of an auto-commit transaction, the array of fids
shuold be put into at least in a LinkedHashSet that preserves insertion 
order.

> 2) Why featureStore.addFeatures() is returning a Set and not a List 
> (losing ordering) ?

No idea. Jody, do you remember why?

Cheers
Andrea