Hi Jesse; It looks like Joshua ran into the same "feature id cannot be trusted until commit" bug that you did. Any chance we can port your hack to geotools for others to make use of?
Joshua Portway wrote: > Hi, > This is obviously a very basic question, but despite all my > research in the user guide and Javadoc I still don't really understand > how this works. A lot of the docs and Javadocs seem to be contradictory. > > According to a conversation on this list a while ago featureIDs > should be relevant to the Feature - and there seem to be schema > methods for creating Features complete with an explicit FeatureId. > However, as soon as I add the feature to a datastore (with addFeature) > it actually changes the featureID - so I can't really see the point of > creating a feature with an ID in the first place. > > Even more mysteriously, addFeatures() is supposed to return a set of > the new FeatureIDs, but seems to just return strings like "new0" which > don't bear any relation to the actual FeatureIds (presumably this is a > bug? I'm using 2.4m4). Gah; we are missing the magic commit part of the equation. Basically until you commit nothing really should happen. They should really only get an ID after the commit statement. I offered to fix this workflow several times (I have a good example of how it should be in GeoAPI) but so far it is rare that anybody notices the problem. Pragmatic advice: use feature ID strings only when working with data that is already committed (ie for selection and updating existing data). Jesse has an idea of using the FeatureID object; and letting those values get updated as the features are assigned real IDs from the datastore (ie during the commit). Right now he creates a listener of WFSDataStore commit and updates the IDs in his fid set - basically a big nasty hack in order to have selection work in uDig. > I also assumed that if I got the schema from a datastore and used the > "create" method of that to directly create a Feature it would actually > be created and added to the datastore, but it seems not. Is there a > way of creating a Feature directly in the dataStore ? If not it seems > the only way is to create one independently and then add it to the > dataStore (at which point its featureId changes). Correct. > Am I misunderstanding how featureIds are used ? Are they supposed to > be basically internal to the dataStore ? I'm very surprised that > there's no simple way to retrieve or modify a Feature in a datastore > given its featureId (the only way seems to be to make a filter, which > seems quite complex). FeatureID stands appart from the rest of the filter specification; it is more of an identifier used when updating a single existing feature in the datastore. The rest of the filter specification is more about doing a query. In WFS1.1 these two ideas have a seperate operations - getFeatures vs getObjectWithId or some such.... > My situation is that my app creates an object for each geographic > region - that object in turn is associated with a Feature in a > datastore. Calling methods on the object to do things like add > geometry should modify the Feature. However I seem to be falling at > the first hurdle - i can't even seem to be able to create a Feature > and retrieve a featureId with which to reference it. > > Am I completely misunderstanding something here ? Let's avoid the problem; add an "ID" attribute and use a propertyName equals filter. Come back to this problem when your application works. 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
