Andrea Aime wrote: >> Andrea here is how you get the correct FeatureIDs after a commit >> (responding on the devel list here): >> 1. Remember the Feature IDs generated as you insert the features; If >> possible grab the actual FeatureId returned by the feature event >> 2. When the commit event goes out ... >> - you can see the Set of actual FeatureIds generated >> - any FeatureIds you held onto will have their internal String >> updated with the correct value > I see... yes, this might actually work without the headache of using > events. Um no - the feature id information is only being communicated properly via events. > A single transaction might have multiple insert elements, each > addressed to a different datastore, and we have to return > the fids in the order of insertion, it seems to me that by just using > the events we cannot guarantee that at all. You will need to remember the order of insertion yourself; the commit event only contains the information allowing you to figure out the final fid. If you want I can store this in a List rather than a Map; so the commit message contains the feature ids in insertion order (makes no difference to the udig case). > Plus, are events triggered when transaction is committed or when the > insert goes? Both. > looking at the code in arcsde it seems when the insert goes, meaning > the fid is not stable. ArcSDE has test cases documenting the expected behaviour; ArcSDE is not yet passing them. > Am I correct in assuming that right now there is no way to tell the > generated fids after the tranaction has been committed? There is a single event fired on commit that contains the information you need; that is fired after the transaction has been committed. > About the FeatureId thing, it's an API change in the feature model, > doing it right one would be better than waiting for 2.6.x user wise, > since we would be grouping the change along with the other feature > model changes, yet this would really be a massive change, and does > not seem it can automated by a simple refactoring... Easiest change would be: complex.getIdentifier() returns Identifier feature.getIdentifier() returns FeatureIdentifier simpleFeature.getID() returns String
This is a long standing request; without this change you need to listen to the insert events to get the FeatureIdenifier. In case it was not clear I need you to hold on to the actual FeatureIdentifier as the system is holding this stuff in a weak map; it is only going to broadcast the correct ids if someone on the outside cares (Gabriel was worried about the amount of memory taken). We have an example of this kind of technique in action; WFSDataStore holds on to FetaureIdentifiers and updates their value internally; that is how jesse got around the API not being well defined for uDig 1.1.0. >> Finally there is an open "bug" here >> (http://jira.codehaus.org/browse/GEO-91) to consider making >> Feature.getID() return a FeatureId; in a similar fashion it would be >> nice to make the insert operation return complete FeatureId objects >> rather than a String. The trick with listening to an event is just >> because we got tired of talking about the problem with a cranky >> geotools-devel list :-) > See above, is listening to events any better than getting the fids out > of FeatureStore.addFeatures()? It does not seem to? Two reason: - addFeatures is returning Strings (not objects that we can update later) - commit does not return a List<Identifier> so we make use of the commit event to hand out that information (ie the final information) Jody ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
