Changes between Version 2 and Version 3 of TopologyCopy

Timestamp:

Apr 9, 2012, 8:18:52 AM (12 years ago)

Author:

martinl

Comment:

—

TopologyCopy

@@ -12 +12 @@
 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).
+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).
 
 To restate, performing steps 2 above forces us to insert records in topology.layer, but until we do step 3 we have nothing to write in the "schema_name", "table_name", "feature_column fields of that table.