Re: [Geoserver-devel] Handling tables with no primary keys

[Jody G. <jga...@re...>]

Rob Atkinson wrote:

> My 2c
>
> The semantics of a feature really require a persistent ID IMHO. Better 
> to get used to the concept of reusable, interoperable data not put 
> effort into solving the wrong problems.

The other side of the coin is trying to ease setup for geoserver.  With 
this in mind I would rather see OIDS used for FeatureID (when a unique 
key is unavailble), and disable transaction support against such tables.

How likly is it that we  will run into GIS systems in the wild that have 
been setup, but lack a unique key? Most postgis tables are set-up with a 
single shapefile import program. Could we ask this program to provide a 
unique key as part of the import process?

Shapefile is similarly troubled when it uses row number as a FeatureID.
A couple of approachs could happend:
- supports the shapefile idea of marking features as deleted - so we can 
preserve rowid = featureid
- port andrea's recent fid_exp work for jdbc DataStores to be part of 
the core DataStore api?

>> Pros:
>> * we can generate a FID for features;
>> * the resulting features can be put into an hash map (that is, loaded 
>> into the
>>  memory data store) without clashes
>
We could just use null for the FID - the datastore really is not 
providing one.  Application like GeoServer can throw a fit and come up 
with some facility for allowing the user to specify a mapping during set up.

>> Cons:
>> * every time a feature is loaded, gets a different UID (since I have 
>> no way to
>>  really identify it)
>> * the ID looks funny...
>>
>> What should we do, refuse to load features from a table because it 
>> does not
>> have primary keys, or adopt the above? Or make it configurable?
>
It does strike me that this is a datastore admin problem and should not 
be left to client applications. Even if that means setting up an extra 
postgis table to persist fid mapping information. It would not be the 
first time, an extra postgis table exists for feature locking information.

Good questions Andrea,
Jody