...
Name | Type | Required | Description |
id | string | yes | Unique identifier |
dbtype | 'oracle' | yes | The name of the driver to use, in this case Oracle |
host | string | yes | The hostname or ip address of the Oracle server |
port | number | yes | The port number that the Oracle instance is running on |
database | string | no | The database parameter for the connection url |
username | string | yes | The userid used when connecting to the database |
password | string | yes | The password used when connecting to the database |
schema | string | no | The schema used when connecting to the database |
minconnections | integer | no | The minimum number of pooled connection. Default 1 |
maxconnections | integer | no | The maximum number of open connections. Default 10 |
validateconnections | boolean | no | Check connection is alive before using it. Default false |
fetchsize | integer | no | The number of records read with each iteraction with the dbms. Default 1000 |
connectiontimeout | integer | no | The number of seconds the connection pool will wait before timing out attempting to get a new connection. Default 20 (seconds) |
primarykeymetadatatable | string | no | The optional table containing primary key structure and sequence associations. Can be expressed as 'schema.name' or just 'name'. Default none |
maxopenpreparedstatements | integer | no | Maximum number of prepared statements kept open and cached for each connection in the pool. Set to 0 to have unbounded caching, to -1 to disable caching. Default 50 |
| geometrymetadatatable | string | no | The optional table containing metadata about the geometry for the tables being accessed via this spatial engine. |
Sub-tags
None
Content
None
Notes
...
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
<spatial:spatialengine id="oracle">
<dbtype>oracle</dbtype>
<host>oradev</host>
<port>1521</port>
<user>gis</user>
<passwd>hak0rz</passwd>
<schema>GIS</schema>
</spatial:spatialengine>
|
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
<spatial:spatialengine id="sdbeos">
<dbtype>oracle</dbtype>
<host>sdbeos</host>
<port>1521</port>
<database>staging</database>
<user>data_viewer</user>
<passwd>ENCSSJKXUMJBMTPGEJFGCXCQFXJJZUTMJZJ</passwd>
<schema>ASSETS</schema>
</spatial:spatialengine>
|
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
CREATE TABLE gt_pk_metadata (
table_schema VARCHAR(32),
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'))
)
|
...
Column | Description |
|---|---|
table_schema | Name of the database schema in which the table is located. |
table_name | Name of the table to be published |
pk_column | Name of a column used to form the feature IDs |
pk_column_idx | Index of the column in a multi-column key. In case multi column keys are needed multiple records with the same table schema and table name will be used. |
pk_policy | The new value generation policy, used in case a new feature needs to be added in the table ('assigned', 'sequence' or 'autogenerated'). |
pk_sequence | The name of the database sequence to be used when generating a new value for the pk_column. |
Geometry metadata table
The Oracle data store will, by default, look into the MDSYS.USER_SDO* and MDSYS.ALL_SDO* views to determine the geometry type and native SRID of each geometry column. Those views are automatically populated with information about the geometry columns stored in tables that the current user owns (for the MDSYS.USER_SDO* views) or can otherwise access (for the MDSYS.ALL_SDO* views).
There are a few hiccups in this process:
- if the connection pool user cannot access the tables (because impersonation is being used) the MDSYS views will be empty, making it impossible to determine either the geometry type and the native SRID
- the geometry type can be specified only while building the spatial indexes, as a index constraint, however such information is often not included when creating the indexes
- the views are populated dynamically based on the current user, if the database has thousands of tables and users the views can become very slow
The database administrator can address the above issues by manually creating a geometry metadata table describing each geometry column, and then indicate its presence among the Oracle data store connection parameter named geometrymetadatatable (either as a simple table name, or a schema qualified one). The table has the following structure (the table name is free, just indicate the one chosen in the data store connection parameter):
| Code Block |
|---|
CREATE TABLE GEOMETRY_COLUMNS( F_TABLE_SCHEMA VARCHAR(30) NOT NULL, F_TABLE_NAME VARCHAR(30) NOT NULL, F_GEOMETRY_COLUMN VARCHAR(30) NOT NULL, COORD_DIMENSION INTEGER, SRID INTEGER NOT NULL, TYPE VARCHAR(30) NOT NULL, UNIQUE(F_TABLE_SCHEMA, F_TABLE_NAME, F_GEOMETRY_COLUMN), CHECK(TYPE IN ('POINT','LINE', 'POLYGON', 'COLLECTION', 'MULTIPOINT', 'MULTILINE', 'MULTIPOLYGON', 'GEOMETRY') ) ); |
When the table is present the store will first search it for information about each geometry column to be classified, and fall back on the MDSYS views only if such table does not contain any information.