As far as I can tell there isn't actually a simple way to retrieve a Feature from a dataStore, modify it, and then write it back to the dataStore - is this correct ?
From looking at the sample code and searching the Javadocs it seems that the only way to modify a feature is to use the FeatureStore.modifyFeatures() method using a filter which filters only the Feature I'm interested in. Also, it looks like using this technique I can only modify one attribute of the feature at a time, so I need to know what's changed and then do the procedure above once for each attribute that's changed. Is this correct ?
If it's correct can you explain why there isn't just a dataStore.modifyFeature(Feature) method which would just write a feature back to the datastore?
I keep getting the feeling that there must be something really fundamental I'm missing, or that I must be trying to use the library in the wrong way because the problems I keep bumping into seem like most fundamental operations (creating and modifying features, for instance) but they seem to be very complicated. It's quite hard to understand why there's a batch operation for modifying a single attribute of a bunch of Features, but (apparently) no method for just writing a single Feature back to the store - unless I'm completely misunderstanding how to use a dataStore or something.
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
