Thanks for the clarification Jody,I'm still confused though I'm afraid - I tried adding an "ID" attribute to my FeatureType as you suggested. Being an ID field I assumed that it shouldn't be nullable, so I specified it as that, but when I try to use addFeatures now (to add a feature that *does have* an ID attribute) I get an exception thrown. It looks as if the exception is being caused because internally addFeatures (actually the featureWrite.next() implementation) is trying to create a new "blank" feature. This new internally created feature has all null attributes and so causes an exception to be thrown because the ID attribute isn't supposed to be nullable. I guess I can work around it by making the ID attribute nullable, but this seems to imply that it's not actually possible to use non-nullable attributes.
I guess I was expecting Features to act more like Entities do in Java Persistence Architecture - Ie. they would be local proxies for the remote object, and changing them and persisting the change would "just work". Once I discovered that wasn't the case I kind of assumed I'd store an ID to the Feature I was after and then retrieve it, modify it, and save it manually - but the ID seems to be quite a slippery creature which makes it quite unsuitable for using as a reference to the object. I do find it strange that there isn't an easy way to *somehow* keep track of a Feature you've added to a dataStore.
I'm thinking of trying the following - adding a nullable ID attribute to my schema, creating Features with an explicit ID attribute as you suggest, and then adding them to the dataStore. Immediately searching for the Feature I just added using the ID attribute, and then remembering the feature ID of the feature I get back. Hopefully this featureID will be stable over modifications to the feature ?
Some suggestions for clarifying the Javadocs :In some places they talks about letting the dataStore generate the featureID as being a bad thing ("Generating a FeatureID is less than ideal, as a FeatureID should be something special about the "real world object" being modeled as a feature." - FeatureType.create), and in other places it talks about it being a good thing ("One thing that is really nice about the approach to adding content is that the generation of FID is not left in the users control." - FeatureWriter).
There's also quite a lot of conflicting information about deprecated methods etc. It's quite confusing for the beginner - eg. FeatureType.create says the method is deprecated and from 2.3 onwards there will be a "FeatureFactory" class - from what I can tell this seems to be an idea that's been abandoned, but the warnings etc. are still in there so can lead to very frustrating wild goose chases to find the "right" way to do it.
thanks again for the help, Josh On 11 Sep 2007, at 00:31, Jody Garnett wrote:
Joshua Portway wrote:I'm more and more convinced this is a bug - certainly it doesn't seem to behave as described in the docs :Not really; the features are assumed to be "not yours" - you gave them to the DataStore (which may be on a different machine). The other machine is responsible for putting the feature id "handle" on them, and when you call addFetures( features ) they are not even sent over yet, it is only when you call commit() that they make the trip.When I add a feature using FeatureStore.addFeatures I get incorrect FeatureIds returned.Actually, after walking through the source it turns out that the featureIds are correct at the moment they're returned, but at that point they aren't actually stored yet. As soon as the transaction is committed the new Features seem to get their attributes copied to another Feature with an internally generated FeatureId - so the featureId returned by addFeatures is no longer valid.Is there any way to add a feature to a DataStore and keep some kind of handle to it?So the "improvement" I had figured out? It was simply making commit () return the Set<FeatureId>.Jesse has a slightly more slick idea; hand you back FeatureId objects, and when commit is called update those objects with their "real" value from the database.Jody
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------- 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
