Hey Ben thanks for the reply.
On Fri, Apr 5, 2013 at 2:09 AM, Ben Caradoc-Davies <
[email protected]> wrote:
> On 04/04/13 22:57, Gabriel Roldan wrote:
>
>> What would be the impact to geoserver if a datastore does not respect
>> the convention of providing feature ids as <simple type name>.<backend
>> identifier>
>>
>
> Gabriel, I don't think this is any sort of convention, just the current
> implementation.
>
>
> I'm betting the only compromised feature for geoserver would be the WFS
>> GetFeature request with featureId= parameter?
>>
>
> app-schema DataAccess supports any valid gml:id (xs:NCNAME) and works
> correctly with featureid.
>
But does it even if typeName is not given to GetFeature? (I seem to
remember typeName is optional for a featureId request?)
In any case, thanks for your insights, just what I needed to know.
Cheers,
Gabriel
>
> You wrote the ancestor of this plugin, back in 2006 or so. :-)
>
>
> Also, am I right this is one of those kind of mandatory conventions,
>> like the one for datastore factories to support a "namespace" parameter,
>> but that are not set in stone anywhere?
>> The feature id issue bothers me since a while now and would like to
>> gather opinions on whether it shouldn't be mandatory for geotools
>> datastores to prefix the feature ids that way.
>>
>
> It is not. We already have one (app-schema) that does not.
>
>
> It looks to me like a WFS
>> think leaking down to the data access layer, in order for GeoServer to
>> be able of supplying unique ids at the service instance level, which in
>> an ideal world should be GeoServer's responsibility (like in GeoServer
>> being in charge of prefixing the workspace + type name to the geotools
>> provided feature id).
>>
>
> +1.
>
> In my view, anything that attempts to parse a featureid is relying on
> implementation behaviour, not a published interface.
>
> A datastore should be free to use any (xs:NCNAME) feature id, as long as
> it is able to parse them from Query objects that it is given. WFS
> GetGmlObject is implemented by querying every data store that is a
> GmlObjectStore. This does raise the possibility of a feature id collision
> if two stores both provide features with the same id; this violates the WFS
> spec.
>
> Kind regards,
>
> --
> Ben Caradoc-Davies <[email protected]>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
