While I realize that some users have this problem I generally still
think it is a bad idea to make any promises about supporting inputting
of ID's.
What about the notion of a wrapper datastore that can basically maintain
mappings in a table (similar to how versioning ds uses tables to
maintain versioning info).
It would also0 have the nice side affect of not further complicating the
jdbc ng code which has seen a wack of features and development over the
last year. Not a bad thing of course but the more we add to it the more
monolithic and harder to maintain it becomes.
2c.
-Justin
On 4/9/10 1:28 AM, Andrea Aime wrote:
> Hi,
> while working on the GeoServer synchronisation problem
> I stumbled into what seems a serious limitation of the
> Geotools datastore design.
>
> In particular I need to insert features into a database
> whose feature id is provided by the user and should be
> maintained as-is. In the synch case the fid is a UUID
> generated on another node for a newly inserted feature,
> and of course to keep the net in synch all nodes must
> use the same identity.
>
> For that particular case I worked around the issue in
> the versioning data store by leveraging some knowledge
> of the internal implementation, by knowing that the
> feature returned from the writer is a MutableFIDFeature
> one [1]
>
> That is old JDBC code, and internally the custom UUID FID
> mapper first tries to unpack the primary key, checking
> if it's a valid UUID, if so it reuses the value,
> otherwise it generates a new one.
>
> Just today I stumbled into a user having the same need against
> the new JDBC data stores.
> I'm wondering if/how we can generalize a bit more this behavior,
> also under the consideration that the WFS standard itself
> allows the primary keys to be both generated or assigned
> in transactions [2]
>
> Of course one way is to replicate sort of the same trick
> for JDBCFeatureStore, leveraging the knowledge of the
> feature returned by the writer to stick a FID into it,
> and then change JDBCDataStore.getNextValue() so that it
> also takes the current Feature and tries to unpack the
> primary key instead of blindly trying to generate a new
> value.
> This would also be an acceptable solution to me btw,
> and I guess it would cover 90% of what is needed:
> shapefile datastore cannot accept user provided pks,
> the only other one I can think of that would need
> to use assigned values is probably the WFS data store
> one (and maybe the SDE one? not sure).
>
> Opinions?
>
> Cheers
> Andrea
>
>
> [1] -----------------------------------------------------
>
> public List<FeatureId> addFeatures(
> FeatureCollection<SimpleFeatureType, SimpleFeature>
> collection) throws IOException {
> List<FeatureId> addedFids = new LinkedList<FeatureId>();
> String typeName = getSchema().getTypeName();
> SimpleFeature feature = null;
> SimpleFeature newFeature;
> FeatureWriter<SimpleFeatureType, SimpleFeature> writer =
> getDataStore()
> .getFeatureWriterAppend(typeName, getTransaction());
>
> Iterator iterator = collection.iterator();
> try {
>
> while (iterator.hasNext()) {
> feature = (SimpleFeature) iterator.next();
> newFeature = (SimpleFeature) writer.next();
> try {
> newFeature.setAttributes(feature.getAttributes());
> } catch (Exception writeProblem) {
> throw new DataSourceException("Could not create " +
> typeName
> + " out of provided feature: " +
> feature.getID(), writeProblem);
> }
>
> // preserve the FID, it could come from another node
> ((MutableFIDFeature)
newFeature).setID(feature.getID());
>
> writer.write();
> addedFids.add(newFeature.getIdentifier());
> }
> } finally {
> collection.close(iterator);
> writer.close();
> }
> return addedFids;
> }
>
>
> [2] -----------------------------------------------------
>
> <xsd:simpleType name="IdentifierGenerationOptionType">
> <xsd:restriction base="xsd:string">
> <xsd:enumeration value="UseExisting">
> <xsd:annotation>
> <xsd:documentation>
> The UseExsiting value indicates that WFS should not
> generate a new feature identifier for the feature
> being inserted into the repositry. Instead, the WFS
> should use the identifier encoded if the feature.
> If a duplicate exists then the WFS should raise an
> exception.
> </xsd:documentation>
> </xsd:annotation>
> </xsd:enumeration>
> <xsd:enumeration value="ReplaceDuplicate">
> <xsd:annotation>
> <xsd:documentation>
> The ReplaceDuplicate value indicates that WFS should
> not generate a new feature identifier for the feature
> being inserted into the repositry. Instead, the WFS
> should use the identifier encoded if the feature.
> If a duplicate exists then the WFS should replace the
> existing feature instance with the one encoded in the
> Insert action.
> </xsd:documentation>
> </xsd:annotation>
> </xsd:enumeration>
> <xsd:enumeration value="GenerateNew">
> <xsd:annotation>
> <xsd:documentation>
> The GenerateNew value indicates that WFS should
> generate a new unique feature identifier for the
> feature being inserted into the repositry.
> </xsd:documentation>
> </xsd:annotation>
> </xsd:enumeration>
> </xsd:restriction>
> </xsd:simpleType>
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
