Changes between Version 1 and Version 2 of TopologyCopy

Timestamp:

04/09/12 08:18:24 (13 years ago)

Author:

martinl

Comment:

--

TopologyCopy

@@ -7 +7 @@
 
  1. Copy all node,edge,face primitives to a different topology schema
- 2. Copy all TopoGeometry definitions (from the relation table and the topology.layer table)
- 3. Make the new TopoGeometry available again somewhere (in some actual table column)
+ 2. Copy all `TopoGeometry` definitions (from the relation table and the topology.layer table)
+ 3. Make the new `TopoGeometry` available again somewhere (in some actual table column)
 
-The nice thing about this is that primitive identifiers, as well as layer identifiers and TopoGeometry identifiers are all valid on a per-topology basis, so simply copying a whole topology schema and any rows in topology.layer would get you in a situation where you'd have every TopoGeometry from source topology have a corresponding TopoGeometry in target topology having the _same_ identifier. This is useful as you can then "rebind" a TopoGeometry from one topology to the other by simply modifying its "topology_id" field.
+The nice thing about this is that primitive identifiers, as well as layer identifiers and [wiki:UsersWikiTopoGeometry TopoGeometry] identifiers are all valid on a per-topology basis, so simply copying a whole topology schema and any rows in topology.layer would get you in a situation where you'd have every [wiki:UsersWikiTopoGeometry TopoGeometry] from source topology have a corresponding [wiki:UsersWikiTopoGeometry TopoGeometry] in target topology having the _same_ identifier. This is useful as you can then "rebind" a [wiki:UsersWikiTopoGeometry TopoGeometry] from one topology to the other by simply modifying its "topology_id" field.
 
 Only trouble would be tweaking the copies of topology.layer records (the rows defining the layers, and thus completing definition of the TopoGeometry which belong to those layers) as those records are currently expected to associate a conceptual layer to an actual column of a database table. But we don't have those table columns yet (and we may even not want it).
@@ -22 +22 @@
 With this proposal, steps 1 and 2 described in the introduction are seen as a single step, effectively rendering the relation table and the rows in topology.layer (required for proper interpretation of the relation table) as a fundamental part of the topology structure.
 
-In order to decouple the "definition" of the TopoGeometry from their deployment in actual table, we'd need to allow not specifying a schema/table/col in topology.layer records. Such records might then represent "detached layers", that are conceptual layers (set of TopoGeometry objects) which are not bound to a specific database column.
+In order to decouple the "definition" of the `TopoGeometry` from their deployment in actual table, we'd need to allow not specifying a schema/table/col in topology.layer records. Such records might then represent "detached layers", that are conceptual layers (set of `TopoGeometry` objects) which are not bound to a specific database column.
 
 This would imply changing the current definition of topology.layer table in a normalized form (for example splitting in two tables, one with structural definition fields, another with deployment info) or using placeholder values for the three fields which would be meaningless for "detached layers".