Jody Garnett ha scritto: > 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.
So FeatureId by itself is useless? If I cannot keep a reference to the FeatureId returned on addFeatures() and be sure they will change once the transaction is committed, what's the use of them? If I have to use events, I can just grab the fid strings. >> 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). The list is the bare minimum, otherwise I cannot respect the WFS standard. So this means I will have to remember I had 3 insertions on ft1, then 2 on ft2, then 2 on ft1 (again), then 3 on ft3, ... and when I get back the events (one per feature store afaik, right?) I'll have to put back togheter a proper list of fids. Glab... cumbersome at best, but may work. >> 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. A single one per feature store? Or is there some place where I can register a transaction listener? >> 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 I see... yeah, not very worrisome. Who's gonna do this change? This is a resource gathering request. > 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). I bet, and with good reason. > 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) Confused here, do you want to change commit to return the list or create a new event that reports the commit? 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
