Jody Garnett ha scritto: >> 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.
Nope, not fully true, see following. >> 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. Yeah, it builds one in addFeatures if transaction is auto-commit, and destroys it before exiting. That is, it creates a transction that lives as long as the addFeatures call. Externally, you don't notice this, and things just work. >> 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. Javadocs are clear, but are lying too: > /** > * Adds all features from the passed feature collection to the datasource. > * > * @param collection The collection of features to add. > * @return the FeatureIds of the newly added features. > * > * @throws IOException if anything goes wrong. > */ > 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. I disagree. Order still matters, and I don't like the idea of having only commit return a set of fids. You can fiddle as long as you want, but order may still be preserved if every insert you do hits the WFS server is the same order its done. Just return every fid that has been created, in the order the features have been inserted, and removing those that have been deleted. Moreover, Transaction should have a method getFids() that returns a list of fids that have been generated so far, even before the transaction ends: most data stores will be able to return fids right away, whilst WFS will return an emtpy list up until commit. Finally, methods such as addFeatures() should return a populared List when fids are generated right away, and an emtpy collection otherwise, without giving the illusion you're getting good fids while you're not. Getting fids during the transaction is important for certain algorithms that need to keep on playing with the inserted features during the trasaction. Database people will expect to have the fids right away, because primary keys are generated on inserts, not on commits. That my point of view, at least. Have interfaces that allow for the general case to be handled, but allow the most common behaviour to be used too. Cheers Andrea ------------------------------------------------------------------------- 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
