[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Re: [udig-users] ID of FID
|
andrea antonello wrote:
Hi, I'm taking this to the devel list, since I also need some clarification.
Am I right in saying that the primary key column is taken as the FID field?
Depends which DataStore; you can also have multiple primary keys - for
details see the JDBCDataStore FidMapper class.
This, in my opinion brings to different behaviours.
Imagine I have a postgis table with 4 fields, one of which is primary key.
case 1: I load it into udig through the postgis connection. Then I
export the layer to shapefile and what I gain is a file containing
only 3 fields, since the original primary key field was transformed
into FID and therefore distorting it, and also the FID is not
exported.
case 2: I export the shapefile through pgsql3shp. I get my nice
shapefile with all 4 fields.
Is this a known behaviour? Is this a proper behaviour?
It is up to you the developer what you want to do; some file based
datastore formats can store the feature id you provided (the property
datastore can for example); others like shapefile have a very simple
definition of primary key (ie row number).
I have a strange feeling in knowing that I will lose a field in exporting a postgis layer through udig.
Please note that if you import the shapefile you exported as pgsql3shp
you will have 4 fields AND a primary key (so 5 bits of information).
If your table had an ID column that was not a primary key I think the
default behavior is to use the "oid" information for the row - which is
only stable for rows that have not been updated or something.
I think you can set a Hint or configuration option to include keys as
readable attributes (up to you).
Jody
