Hi all,
the WFS 1.1 allows for multiple key generation strategies, and asks the server
to implement at least one: "A specific web feature service implementation must
support one of these methods of assigning features identifiers to new feature
instances and may support all methods".
Where the methods are:
* GenerateNew (default)
The web feature service shall generate unique identifiers for all newly inserted feature instances.
* UseExisting
In response to an <Insert> operation, a web feature service shall use the gml:id attribute values on inserted features and elements. If any of those IDs duplicates the ID of a feature or element already stored in the WFS, the WFS shall raise an exception.
* ReplaceDuplicate
A WFS client can request that the WFS generate IDs to replace the input values of gml:id attributes of feature elements that duplicate the ID of a feature or element already stored in the WFS, instead of raising an exception, by setting the idgen attribute of the InsertElementType to the value "ReplaceDuplicate".
Now, depending on the FID mapper we may support one but not the others.
- GenerateNew works only with auto-generated primary keys (sequences, serials)
and were the primary key is provided by the user and mapped among the
attributes (so we look into the to "generate" the fid).
It's also the only one working with shapefiles and other file based things that
do not really have
- UseExisting works only with user assigned ids, possibly with only one column,
otherwise the fid mapper will try and parse the fid provided into its components.
For sure it won't work were the id is a serial, we may either get a conflict or
setup for one in the future (we could update the sequence to the value next to
the biggest inserted, but that's a recipe for disaster since we may end up very
near to the sequence overflow).
- ReplaceDuplicate does not really work with any datastore/fidmapper in the
case were an actual replacement is needed afaik. Unless we create a new kind
of fid mapper that uses big strings and a GUID generator....
Long story short, what we do really support depends on the feature type.
Too bad the WFS 1.1 capabilities lists the idgen capabilities only among
the Transaction operation type, and does not allow to attach it to the feature type.
So, I'm wondering, what do we do? Do we declare we support GenerateNew and UseExisting,
and fail on pk generation if the one used by the user does not match the fidmapper or datastore
way of doing things? Remeber, for JDBC data store we may have some limited choice,
but for other data stores we're generally stuck and must accept whatever the datastore
providers.
Hi all,
the WFS 1.1 allows for multiple key generation strategies, and asks the server
to implement at least one: "A specific web feature service implementation must
support one of these methods of assigning features identifiers to new feature
instances and may support all methods".
Cool nice to see some attention paid to the idea of identity.
Now, depending on the FID mapper we may support one but not the others.
Is FID mapper escaped the bounds of the JDBC implementations? I would like to propose a slightly
different approach (see below).
Long story short, what we do really support depends on the feature type.
Too bad the WFS 1.1 capabilities lists the idgen capabilities only among
the Transaction operation type, and does not allow to attach it to the feature type.
That is too bad, our traditional approach has always been to "build up" functionality to the point
where it matches WFS (or at least open the door to allow applications to provide this as per locking).
So, I'm wondering, what do we do? Do we declare we support GenerateNew and UseExisting, and fail on pk generation if the one used by the user does not match the fidmapper or datastore
way of doing things? Remeber, for JDBC data store we may have some limited choice,
but for other data stores we're generally stuck and must accept whatever the datastore providers.
No reason to fail, remember that the goal for 2.4 is to start allowing applications such as GeoServer to
take control of this kind of thing.
Whatever the raw datastore provides you in terms of an array of objects and schema information you
should be able to provide your own FeatureType and Feature implementation to account for each of
the above schemes.
As an example to support the user supplied ID you can use the property datastore (which allows this) or ...
Map an "ID" "attribute" to the FeatureID using a geoserver supplied FeatureTypeFactory and FeatureFactory.
When feature id is disjointed from the underlying dataset like this (as would be the case for a table or shapefile with an "id" entry) you would only expect good FidFilter performance when an attribute index exists on "id" ...
Is FID mapper escaped the bounds of the JDBC implementations? I would like to propose a slightly
different approach (see below).
No, but Geoserver does pass CITE tests only with jdbc datastores anyways, with Postgis in particular,
don't know about the others. Since we are speaking about transactions...
So, I'm wondering, what do we do? Do we declare we support GenerateNew and UseExisting, and fail on pk generation if the one used by the user does not match the fidmapper or datastore
way of doing things? Remeber, for JDBC data store we may have some limited choice,
but for other data stores we're generally stuck and must accept whatever the datastore providers.
No reason to fail, remember that the goal for 2.4 is to start allowing applications such as GeoServer to
take control of this kind of thing.
Whatever the raw datastore provides you in terms of an array of objects and schema information you
should be able to provide your own FeatureType and Feature implementation to account for each of
the above schemes.
As an example to support the user supplied ID you can use the property datastore (which allows this) or ...
Map an "ID" "attribute" to the FeatureID using a geoserver supplied FeatureTypeFactory and FeatureFactory.
When feature id is disjointed from the underlying dataset like this (as would be the case for a table or shapefile with an "id" entry) you would only expect good FidFilter performance when an attribute index exists on "id" ...
hmm... this does not make sense to me.
What do you propose, that geoserver starts using an external id subsystem other than the table primary
key? This would be complex and very dangerous at the same time.
It's not about the application taking control in my mind, it's just that primary keys in the database
matches or does not matches the idgen request (fidmapper is just a framework to make the primary
key meaning and nature usable from geotools, does not try to force a different meaning...)