1.14 Spatial and Graph Topology Support

This section describes special considerations and techniques for using Workspace Manager with tables in Oracle Spatial and Graph topologies,

Topologies are documented in Oracle Spatial and Graph Topology Data Model and Network Data Model Graph Developer's Guide.

A topology consists of feature tables, as well as tables with names in the form <topology-name>_NODE$, <topology-name>_EDGE$, <topology-name>_FACE$, <topology-name>_RELATION$, and <topology-name>_HISTORY$. If you want to version-enable any topology tables, you must version-enable all tables associated with the topology. To do so, you must specify the topology name as the table_name parameter to the EnableVersioning procedure, and you must specify the isTopology parameter as TRUE. For example:

EXECUTE DBMS_WM.EnableVersioning(table_name => 'xyz_topo', isTopology => TRUE);

The preceding example version-enables the xyz_topo topology; that is, it version-enables all feature tables associated with the xyz_topo topology, as well as the XYZ_TOPO_NODE$, XYZ_TOPO_FACE$, XYZ_TOPO_EDGE$, XYZ_TOPO_RELATION$, and XYZ_TOPO_HISTORY$ tables.

A version-enabled topology must have at least one feature table.

To disable versioning on any topology tables, you must disable versioning on all tables associated with the topology by specifying the topology name as the table_name parameter to the DisableVersioning procedure and the isTopology parameter as TRUE.

However, exceptions apply to the preceding guidelines about version-enabling and version-disabling topology tables in the following cases:

• If a feature table of a topology is the child table of a referential integrity constraint with CASCADE option with a table that is not in the topology

• If a feature table of a topology is the parent table of a referential integrity constraint with a table that is not in the topology

In these cases, you must version-enable or version-disable the feature table separately. That is, first call the EnableVersioning or DisableVersioning procedure on the feature table (along with any tables required by the referential integrity constraint), and then invoke the EnableVersioning or DisableVersioning procedure specifying the topology name.

• Locking Considerations with Topologies
  
• Additional Considerations with Topologies
  

1.14.1 Locking Considerations with Topologies

To lock or unlock rows in tables associated with a topology, you must specify the topology name as the table_name parameter to the LockRows or UnlockRows procedure, and you must identify the window containing the rows by using the Xmin, Ymin, Xmax, and Ymax parameters. You must also not specify the where_clause parameter. For example:

EXECUTE DBMS_WM.LockRows (workspace => 'ws1', table_name => 'xyz_topo', Xmin => 0.1, Ymin => 0.1,  Xmax => 0.5, Ymax => 0.5 );

The preceding example puts version locks on all the rows of the specified topology contained in the specified window. To edit the elements of a topology in a workspace (including the LIVE workspace), follow these steps:

1. Invoke the LockRows procedure to put version locks on all the elements of the topology contained in a window of interest.

2. Invoke the Oracle Spatial and Graph Topology Java client loadWindow method for the same window of interest.

1.14.2 Additional Considerations with Topologies

The following additional considerations apply to using Workspace Manager with Spatial and Graph topologies:

• You must invoke the SDO_TOPO.INITIALIZE_METADATA procedure at least once on a topology before you version-enable the tables associated with the topology. (You can also invoke the SDO_TOPO.INITIALIZE_METADATA procedure as needed after version-enabling a topology.)

• Do not use the MergeTable, RefreshTable, or RollbackTable procedure on a version-enabled table associated with a topology. Instead, use the MergeWorkspace, RefreshWorkspace, or RollbackWorkspace procedure to merge, refresh, or roll back tables associated with a topology.