控制空间数据库中特征ID的生成¶
介绍¶
所有空间数据库数据存储（postgis、oracle、mysql等）通常从表主键中派生功能ID，并假定在需要生成新功能（wfs insert操作）时，如何定位键的下一个值的某些约定。
常见的约定依赖于查找自动增量列（postgis）或查找以特定约定命名的序列，例如 <table>_<column>_SEQUENCE （甲骨文案例）。
如果找不到上述任何一个，通常存储会在每次新请求时返回到生成随机特征ID，使表不适合基于特征ID的搜索和事务。
元数据表说明¶
这些默认值可以通过创建 primary key metadata table 它指定要使用的列以及用于生成新主键值的策略。可以使用此SQL语句创建（模式限定的）表（此语句对PostGIS和Oracle有效，使其适应特定的数据库，如果需要，可以在末尾删除检查）：：
--PostGIS DDL
CREATE TABLE my_schema.gt_pk_metadata (
table_schema VARCHAR(32) NOT NULL,
table_name VARCHAR(32) NOT NULL,
pk_column VARCHAR(32) NOT NULL,
pk_column_idx INTEGER,
pk_policy VARCHAR(32),
pk_sequence VARCHAR(64),
unique (table_schema, table_name, pk_column),
check (pk_policy in ('sequence', 'assigned', 'autogenerated'))
)
--ORACLE DDL
CREATE TABLE gt_pk_metadata (
table_schema VARCHAR2(32) NOT NULL,
table_name VARCHAR2(32) NOT NULL,
pk_column VARCHAR2(32) NOT NULL,
pk_column_idx NUMBER(38),
pk_policy VARCHAR2(32),
pk_sequence VARCHAR2(64),
constraint chk_pk_policy check (pk_policy in ('sequence', 'assigned', 'autogenerated')));
CREATE UNIQUE INDEX gt_pk_metadata_table_idx01 ON gt_pk_metadata (table_schema, table_name, pk_column);
可以为该表指定不同的名称。在这种情况下，必须在 primary key metadata table 存储的配置参数。
下表描述了元数据表中每一列的含义。
Column |
Description |
table_schema |
表所在的数据库架构的名称。 |
table_name |
要发布的表或视图的名称 |
pk_column |
用于形成要素ID的列的名称 |
pk_column_idx |
多列键中列的索引，否则为空。如果需要多列键，将使用具有相同表架构和表名的多个记录。 |
pk_policy |
新的价值生成策略，用于表中需要添加新功能的情况（遵循WFS-T插入操作）。 |
pk_sequence |
为pk_列生成新值时要使用的数据库序列的名称。 |
的可能值 pk_policy 是：
assigned .将使用新插入功能中的属性值（假定已启用“公开主键”标志）。
sequence . 属性的值将从
pk_sequence列。autogenerated .该列为自动递增列，将使用自动递增中的下一个值。
将元数据表与视图一起使用¶
geoserver可以发布无问题的空间视图，但通常会产生两种副作用：
该视图被视为只读
功能ID是随机生成的
元数据表也可以引用视图，只需在 table_name 列：这将导致稳定的ID，并且在支持可更新视图的数据库中，它还将使代码将视图视为可写的（因此，允许对其使用WFS-T）。