[TinyOWS-users] fids in database views

[Olivier Courtin]

On Sep 24, 2010, at 3:35 PM, Rahkonen Jukka wrote:

Jukka,

> Some more thoughts about fids and views.
>
> - Views which include joins usually need several columns for building
> something unique, typically PK_table1+PK_table2.

Yes,
Even if i'm not sure to implement this feature in the earlier version

> - Attribute used for a primary key and fid should normally not be
> included as a normal attribute in the schema. Especially this is the
> case with WFS-T, users should definitely not edit the fids!

Do you have more information on this point Jukka ?
I never seen anything on the spec related how to handle PK.

If i remember right they are not exposed in 1.0.0 CITE tests,
and GeoServer have a specific 'expose PK'  parameter like,
to be able to expose them anyway.

> - However, sometimes database is defined so that PK is made from
> person-IDs or cadastrial IDs or something else that is also  
> important as
> a normal attribute. They are harder to handle with WFS-T inserts,
> perhaps the only possibility is just to trust the user and accept what
> comes in with the insert message. If it is not unique the database  
> will
> not take it but of course it can be unique but wrong it user makes an
> error. For my mind it would not be a crime to decide that TinyOWS will
> not support such tables for WFS-T at all.

I like the idea to trust the client on this one,
with 'only' the check to UNIQUE PK server side

> - However, it should be possible to use those tables read-only in  
> such a
> way that both the fids are unique and correct and the PK field is
> included as an attribute in the output GML.
> - Most simple way to do this is to make a view and select the primary
> key column two times like
> CREATE VIEW view as (SELECT person_id PK, person_id person_id...)
>
> In the confifuration PK will be defined as a primary key. WFS server
> uses that for creating fids and eats that column away from the output
> just as usual. The same information is included also in the person_id
> field and that is included as a normal attribute.
>
> Would this be simple enough? It is not very hard to document "Primary
> key columns are not included in the output GML. If that information is
> needed, make a view and select PK column two times with different  
> names.
> Do not use this for WFS-T".

I don't really like the idea to alter the data structure with a double  
PK column,
i feel more confortable with an optional parameter in config.xml on  
layers.
(to expose (or not))
>
--
Olivier