The problem 

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".

The methods are:

Our current support

This is less how FID are managed by our current datastore. I made an informal review, feel free to correct my findings:

Datastore

FID handling

Idgen supported

JDBC data stores (Postgis, Mysql, Hsql, DB2, Oracle)

FidMapper framework.
Handles:* single varchar column

  • int column, maxinc, sequence or serial
  • multicolumns, url-encode and catenate values (basically, assigned in columns)

Depending on the fid mapper, UseExisting (single and multicolumn) or GenerateNew (single and multicolumn may work when the column is shown in the feature type, and will work with increment ones).
ReplaceDuplicate may work with increment ones, but it's bound to be dangerous

Shapefile

Reading, FID is the row number, during writing whatever is in the FID is ignored, only order is imporant.

GenerateNew

ArcSDE

ArcSdeFeatureWriter seems to ignore the FID for new features, and uses whatever FID it produced for updating existing features. There's no control over feature id apparently.
There is an improvement, though, pending to be merged back from complex-features branch to trunk, that would allow to use one or another strategy based on what exactly is happening on the database for each feature type. 

GenerateNew
Possible: GenerateNew, UseExisting 

MifDataStore

FID is ignored during writing (MIFFile.Writer, line 1748)

GenerateNew

PropertyDataStore

Uses whatever ID has been assigned to features, no ID generation going on apparently?

UseExisting

GMLDataStore

No write support, so it doesn't apply.

GenerateNew

TigerDataStore

Hmm... does not provide a writer, on its own, so I guess it's read only


VPFDataStore

Same as above


WFSDataStore

Hum.... does not provide a feature writer, so I guess it's read only as well


There's no generic way to tell the above from the data stores.
A way could have been to try and write the feature as is, and check back the fid to see if it has been assigned or if an error occurs, but in some datastore the generated fid won't be seen until closing the transaction and re-reading the features (shapefile for example).
So no luck, it seems we need some in-deep Geotools change in any meaningful way.

What about a new method for the datastore that looks like:

isIdGenSupported(String featureTypeName, int idGenStrategy)

where the strategy is a list of the 3 modes?
The downside is this seems quite ad hoc, what we're really missing is a support for capabilities advertising in datastores (and this one would be one of the capabilities).

 A few notes on FID mappers

Depending on the FID mapper we may support one but not the others, and support may vary depending on how the FidMapper itself is configured.

Actions to solve this problem

Have datastores advertise their FID management capabilities and support at least one method (the other possible solution would have been to check IDs after the fact and make sure they did match with the request, but unfortunately WFS allows generated IDs to be checked only after the transaction is complete).