= Introduction =

When working with topology model, it is often useful to copy a dataset for backup, experimentation or other purposes.
For example,  you may want to get a simplified version of your data for visualization purposes, so you'd pass each edge under ST_Simplify, but don't want to destroy the original data.

Such a copy process would be pretty complex as you'd need to:

 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)

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).

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.

This wiki page is to help with defining interfaces that might take care of those steps for us, in a generic and robust way.

== Proposal1: TopoGeometry collections (conceptual layers) are part of topology structure ==

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.

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".

Also, it would then be advisable to provide functions to "attach" detached layers to existing tables, some kind of AddTopoGeometryLayer when you request to use an existing "detached layer" definition rather than make up a new one.
And maybe also functions to "detach" attached layers and to "drop" attached or detached ones...

... TBC ...