Thanks once again for your help - only one thing still confuses me :
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.There is; add them in, commit, and write down the ID you get back for later.
This is where we came in ! :)When I add Features (at least using addFeatures) the IDs I get back aren't any use - they only seem to refer to transient value objects that got created somewhere along the way (in the transaction "diff" I think) and have now been thrown away when the transaction got committed.
As far as I can tell the only way I can reliably get the featureId of a feature I've just added to the dataStore is to : 1) add some kind of other unique "ID" attribute to the FeatureType as you suggest
2) create new features with this ID filled in 3) add them to the datastore.4) immediately search the datastore using a query to retrieve the object I just added by the new ID attribute
5) remember the featureId of the object I just retrieved.This seems to work for me so far, but seems very long winded and inefficient for something as fundamental as creating a new feature and keeping track of it.
Josh On 11 Sep 2007, at 01:51, Jody Garnett wrote:
One last thing; I am the module maintainer for MemoryDataStore - there is a chance you found a bug. It is supposed to isolate you from the contents stored in side the memory datastore - but if I screwed up it may be adding to your pain.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.wow that is a good catch; we are trying to fix up the feature model right now (it has been broken like this for 5 years) so your test is a good one.I am CCing justin who was recently in there trying to make sure nullable translated to minOccurs=0 maxOccus=1.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".It is more like a database result set.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.It is only slippery when adding. I wish you could create your features and dump them in ;-)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.There is; add them in, commit, and write down the ID you get back for later.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 ?Yes it will. 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
