Joshua Portway wrote: >> There is; add them in, commit, and write down the ID you get back for >> later. > > This is where we came in ! :) Doh! Apparently I should get off this merry go round ;-) > When I add Features (at least using addFeatures) the IDs I get back > aren't any use - they only seem to refer to transient value objects > that got created somewhere along the way (in the transaction "diff" I > think) and have now been thrown away when the transaction got committed. Yeah; and that is the point we gotta problem; because only the transaction commit is in a position to tell us what the real feature ids ended up being. > As far as I can tell the only way I can reliably get the featureId of > a feature I've just added to the dataStore is to : > 1) add some kind of other unique "ID" attribute to the FeatureType as > you suggest > 2) create new features with this ID filled in > 3) add them to the datastore. > 4) immediately search the datastore using a query to retrieve the > object I just added by the new ID attribute > 5) remember the featureId of the object I just retrieved. Yep. > This seems to work for me so far, but seems very long winded and > inefficient for something as fundamental as creating a new feature and > keeping track of it. So far Jesse (the uDig developer) and yourself are the only people trying to do that; most application either dump data in quickly and run away, or work with what is already there.
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
