Andrea Aime wrote: > 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? the addFeatures() method returns a Set<String>; what you want is a List<FeatureId> ... rather than talk through that change with you Jesse has been using FeatureEvents to get the information out.
I provided a good summary over on the GeoTools list.... > If I have to use events, I can just grab the fid strings. fid strings are not really going to cut it; we want the FeatureId so we can smoothly update the value inside. > 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. So let us figure out something that will work ... here is the idea from the GeoTools devel list. > Option Two (for GeoServer) > ======== > Either change api to reflect the need to produce a list of good feature > ids in order with no events > - change addFeatures to return a List<FeatureId> > - record these FeatureIds in a big list from all DataStores > - the values will be correct after commit() is called; > (all the event stuff uDig uses will be needed for the values to be > correct; but geoserver does not have to listen to them at runtime) > > Or change the api so FeatureId is available as you go: > - rather than trust addFeatures to do things; make ... > ComlexAttribute.getIdentifier(): Identifier > Feature.getIdentifier(): FeatureId > SimpleFeature.getIdentifier(): FeatureIdentifier > SimpleFeature.getId(): String // documented to return > getIdentifier().toString() > - keep a list of the FeatureIds as you make features > - after commit() return the list of feature ids >>> 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? A single event is fired per feature store. I see the problem; when inserting into multiple feature stores you are not sure what order was used. > Or is there some place where I can register a transaction listener? We do not have a transaction listener; have a look at the above workflow ideas - I think they are less work then introducing a Transaction listener. > I see... yeah, not very worrisome. Who's gonna do this change? > This is a resource gathering request. I can do the change; you will have to be updating a bunch of code to use it (ie write down the FeatureIds into a List as you create Features). > Confused here, do you want to change commit to return the list or > create a new event that reports the commit? See geotools thread for a clear breakdown of options - and we should probably talk on IRC. 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
