Re: [Geotools-devel] FIDMapper issues

[Jody G. <jga...@re...>]

Andrea Aime wrote:
> Hi,
> I'm looking at this geoserver jira issue:
>
> http://jira.codehaus.org/browse/GEOS-1373
>
> To sum it up in gt2 terms, consider hitting a shapefile datastore 
> wrapping states.shp with a fid filter using "foobar.1", and to
> your surprise, you'll get back a feature whose fid is "states.1".
>   
Actually this is in agreement with the original OGC general model; the 
feature id was designed to be stable and based on the reality of a 
physical feature (so the tact that a feature is coming out of there as 
"states.1" is a bit of a mistake; it is us cutting a corner to come up 
with any kind of id - not even a stable one).

When you are chaining content through a process the feature id is 
supposed to remain pointing to the original content - so the fact that 
it points to "states.1" is a good thing; the problem
is with the first link in the chain.
> The thing is, primary keys and raw feature identifiers of any kind
> are prefixed by the feature type name. I don't know exactly when
> this happened, but it has something to do with the request
> that on a WFS using a feature id you should be able to figure out
> the feature without any specification of the type name (like
> "give me states.1" out of the blue, without telling you from which
> feature type is should be extracted).
>   
Nope it is just supposed to be a stable identifier of the form 
"[A-Z,a-z]+[A-Z,a-z,0-9]*" and prepending the type name was a common 
convention to get an identifier that started with a letter.
> Now, when we go back from the published fid to the raw one, the
> code that does the prefixes just wipes out everything before the
> dot... leading to this issue.
>   
Yeah going from a published fid to a raw one was never the intention; I 
understand that thing may of changed for the GMLObjectId method; so we 
probably need to look again - and possibly revisit our FeatureId policy.
> What about adding a method like "canDecode(String FID)"
> and then have the code in getPKAttribute throw an exception
> if the decode is not possible?
>   
I think that may be needed; in order to support a true GMLObjectId 
method that did not assume anything about the internal structure of the 
FeatureID....

Jody