Miles Jordan ha scritto:
> Hi all,
>
> When I do request a describeFeatureType, the attribute set as the
> primary key doesn't show up - is this normal behavior?
>
> I've been looking through the WFS spec, trying to find if it is
> correct behavior but I can't find anywhere that says to omit it.
>
> To reproduce:
>
http://aadc-dev.aad.gov.au/geoserver/wfs?Request=describeFeatureType&T
> yp
> eName=aadc:AWS_PT
>
> This feature should have an element called 'UFI' which is
the primary
> key for that dataset in Oracle 10g.
>
> Should it show up or is it correct in not doing so (the
same happens
> for all other featuretypes)?
>
That's the default for JDBC data stores, to not include the
primary key
columns in the
feature type. The gt2 API allows to have the primary key attributes
included in the
feature as a datastore wide setting, but no datastore so far makes it
configurable at the
factory level, so Geoserver can't provide you that setting.
If you need key among the attributes, open a jira issue against this
problem.
Btw, primary key does not appear among the attributes, but is
available
in the FID,
the feature id. Is that enough for you?
Cheers
Andrea Aime
Thanks for your reply, Andrea.
Not even the fid is shown in a describeFeatureType (this is geotools
1.3.4 btw). I know the individual values for the primary key are shown
as fid in a getFeature request, but I need to be able to view all
available attributes for a featuretype. IMHO The attribute used as the
primary key should be treated the same as any other attribute.
As another example of this, lets say I want to send a getFeature
request, with a filter that selects a single feature, based on the
unique identifier. The PropertyName element cannot simply contain 'fid',
it has to contain the actual name of the attribute used as the unique
identifier. How would you find out what it is if it is not listed in its
describeFeatureType?
Regards,
Miles
___________________________________________________________________________
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not the
intended recipient, you are notified that use or dissemination of this communication is
strictly prohibited by Commonwealth law. If you have received this transmission in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and
DELETE the message.
Visit our web site at http://www.aad.gov.au/
___________________________________________________________________________
Miles Jordan wrote:
Miles Jordan ha scritto:
Hi all,
When I do request a describeFeatureType, the attribute set as the primary key doesn't show up - is this normal behavior?
I've been looking through the WFS spec, trying to find if it is correct behavior but I can't find anywhere that says to omit it.
To reproduce:
http://aadc-dev.aad.gov.au/geoserver/wfs?Request=describeFeatureType&T
yp
eName=aadc:AWS_PT
This feature should have an element called 'UFI' which is
the primary
key for that dataset in Oracle 10g.
Should it show up or is it correct in not doing so (the
same happens
for all other featuretypes)?
That's the default for JDBC data stores, to not include the primary key columns in the
feature type. The gt2 API allows to have the primary key attributes included in the
feature as a datastore wide setting, but no datastore so far makes it configurable at the
factory level, so Geoserver can't provide you that setting.
If you need key among the attributes, open a jira issue against this problem.
Btw, primary key does not appear among the attributes, but is available in the FID,
the feature id. Is that enough for you?
Cheers
Andrea Aime
Thanks for your reply, Andrea.
Not even the fid is shown in a describeFeatureType (this is geotools
1.3.4 btw). I know the individual values for the primary key are shown
as fid in a getFeature request, but I need to be able to view all
available attributes for a featuretype. IMHO The attribute used as the
primary key should be treated the same as any other attribute.
As another example of this, lets say I want to send a getFeature
request, with a filter that selects a single feature, based on the
unique identifier. The PropertyName element cannot simply contain 'fid',
it has to contain the actual name of the attribute used as the unique
identifier. How would you find out what it is if it is not listed in its
describeFeatureType?
Well, part of the problem is that the FID has a rule that it must not change. If you exposed it as a normal property than one could naively do an update on that field, and accidentally change the FID, which is very bad from the perspective of stable references to features. And if you want to select something by the primary key then you can just use an FID filter.
I concede that this is not the best answer, and I agree that we should offer users the option to expose their primary key as an attribute. But this is the reason we don't expose the primary key as a 'normal' attribute - it's the best thing we've got for a stable, unique identifier, and we don't want it getting changed. And thus I do think the default should be to keep it hidden so it can't be changed. But there should be a way for a user to expose that key, but with the knowledge that it opens that risk (to allow them to do something to protect themselves, make sure it's non-transaction, ect.). Or there should be more options to let users define what fid's they want.
best regards,
Chris
Regards,
Miles
___________________________________________________________________________
Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not the
intended recipient, you are notified that use or dissemination of this communication is
strictly prohibited by Commonwealth law. If you have received this transmission in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and
DELETE the message.
Visit our web site at http://www.aad.gov.au/
___________________________________________________________________________
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
!DSPAM:1003,4522fe9f294341527717022!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Miles Jordan ha scritto:
Thanks for your reply, Andrea.
Not even the fid is shown in a describeFeatureType (this is geotools
1.3.4 btw). I know the individual values for the primary key are shown
as fid in a getFeature request, but I need to be able to view all
available attributes for a featuretype. IMHO The attribute used as the
primary key should be treated the same as any other attribute.
Hmm.... it depends on the point of view you're taking. For example, you don't usually want
primary keys generated automatically to be changed, yet there's nothing in geotools that prevents
you from altering a feature attribute, and as far as I know jdbc data store will merrily send the
database an update statement including primary key column changes (and there only the
eventual violation of primary key uniqueness will protect you from damage).
As another example of this, lets say I want to send a getFeature
request, with a filter that selects a single feature, based on the
unique identifier. The PropertyName element cannot simply contain 'fid',
it has to contain the actual name of the attribute used as the unique
identifier. How would you find out what it is if it is not listed in its
describeFeatureType?
For selecting features based on the id you can use a FidFilter if you want.
Yet, I understand that application needs may make you prefer having it among the attributes...
Ok, I'm opening a Jira issue for this. The solution I can provide you, is to make datastore factories
expose a boolean property that allows you to include the primary keys as fields (for all feature types,
that won't be a feature type specific property anyways).
I can't promise it'll be included in geoserver 1.4.0rc1 thought...
Cheers
Andrea Aime