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 ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
