Andrea Aime wrote: > 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. Some of these are DataStore API questions ... afraid I have not kept up with the user list this last month.
>> 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) ? The DataStore API is broken; returning FIDs is not something that can be accurately done until commit is called; the GeoAPI FeatureStore API has this problem solved (the commit method returns a Set<Identifier>). This is a known screw up that nobody has had time to fix (for quite some time now). > 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 WFSFeatureStore also only works when you are in a transaction. One thing that Jesse did (which is an EVIL hack) was to make a magic FidFilter implementation of his own creation, listen to the commit message and replace the Fids with the real one produced by the commit. But really the Identifiers are not valid until commit is called; the best we can do to Fix the API is make this workflow visible to the developer community. > 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. Andrea I am not sure the WFSDataStore works that way; it needs the Transaction.State memento in order to build up the WFS Transaction Operation. > 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. I thought the javadocs at least were clear; however javadocs is different from "good". For a good solution see the GeoAPI library. > 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? I think this came down to the WFS specification. I would like to return things in the order created, we do have some situtations where something is added, and then removed within one transaction. So we cannot "really" report back FIDS until the transaction is committed. So since we have to cache them all ... and allow them to be hacked at ... order does not mean anything. Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
