Re: [Geotools-devel] FIDMapper issues

[Andrea A. <aa...@op...>]

Jody Garnett ha scritto:
> Andrea Aime wrote:
>>> But yeah it makes sense to me that everyone ignored the OGC General 
>>> Model and started using FeatureId in this way ...
>>>>>> 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....
>>>> As I said, this is implied already by the base WFS spec (and we're 
>>>> failing to support it fully if you have two feature types with the 
>>>> same name in different namespaces, at least in GeoServer).
>>> Cool; so we need to revisit FeatureId definition in GeoTools; the 
>>> target has changed since the OGC General Model and the days of WFS 1.0.
>> Hmmm... ok? How?
> Well it sounds like you are sure on this new definition of feature id; I 
> would start by documenting the FeatureId interface so the intention is 
> clear. I would then start with a well known datastore; say shapefile and 
> see what you can do to make this happen; an obvious one is respecting 
> the "namespace" and "typename" provided as part of the query. The fix 
> may be in the datastore; or it may be in the ReTypeFeatureCollection I 
> am not sure ... If you like the results recommend the practice to others 
> ... and then go on to JDBCDataStore (renegotiate your contract with your 
> subclasses), and AbstractDataStore (same deal).

Whilst you are correct we should do this, supporting fid uniqueness when 
people have configured the same feature type in two different namespaces 
it's such a corner case that I really fear it will stay low low priority
for a long long time ;)

I've opened a jira issue to avoid forgetting about this:
http://jira.codehaus.org/browse/GEOS-1912

Cheers
Andrea