Joshua Portway wrote: > I'm more and more convinced this is a bug - certainly it doesn't seem > to behave as described in the docs : > > When I add a feature using FeatureStore.addFeatures I get incorrect > FeatureIds returned. > > Actually, after walking through the source it turns out that the > featureIds are correct at the moment they're returned, but at that > point they aren't actually stored yet. As soon as the transaction is > committed the new Features seem to get their attributes copied to > another Feature with an internally generated FeatureId - so the > featureId returned by addFeatures is no longer valid. > > Is there any way to add a feature to a DataStore and keep some kind of > handle to it? Not really; the features are assumed to be "not yours" - you gave them to the DataStore (which may be on a different machine). The other machine is responsible for putting the feature id "handle" on them, and when you call addFetures( features ) they are not even sent over yet, it is only when you call commit() that they make the trip.
So the "improvement" I had figured out? It was simply making commit() return the Set<FeatureId>. Jesse has a slightly more slick idea; hand you back FeatureId objects, and when commit is called update those objects with their "real" value from the database. Jody ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
