Jody Garnett ha scritto: > Andrea Aime wrote: >> This limitation is specific of shapefiles, GeoServer expects the >> datastore to be able and provide a valid FID upon insertion, but >> shapefiles cannot determine the proper fid until the transaction is >> closed and the shapefile rewritten (Jody, I remember you talking about >> this "grab the fids after transaction commit" policy, but I actually >> cannot find a datastore independent API to grab the fids after the >> transaction has been committed...) > Actually a few other DataStores have this limitation; ArcSDE for example > - which is one of the reasons I have been working hard with Gabriel to > see this issue addressed. As you indicated PostGIS is one of the only > sane choices here just because the amount of testing. > > 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. 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. Plus, are events triggered when transaction is committed or when the insert goes? looking at the code in arcsde it seems when the insert goes, meaning the fid is not stable. Am I correct in assuming that right now there is no way to tell the generated fids after the tranaction 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... > 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? Cheers Andrea ------------------------------------------------------------------------- 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
