Updating dm objects
2020-04-17
This draft describes update operations on dm objects.
Operations on a dm object are generally transient or ephemeral. Resulting dm or table objects must be stored in a new object, otherwise they are lost.
Design
- records tables from a source dm are appended/updated/upserted/removed/replaced/… from the target dm
- both dm must be compatible
- same source
- source has no extra tables and columns
- PK columns must be present in source
- dry run supported: use transient operations instead of materialization
- check integrity constraints are still valid after running
- compare before-after state
- transactions out of scope, caller can use
DBI::withTransaction()
Challenges
- determine table name for remote tables
- make this work for both local and remote tables and for extensions
- some operations need top-down, others need bottom-up
- fixed set of operations, each op knows its “direction”
- pass key columns to
tbl_xxx() operations
- for now with a separate
keys argument (TBD), later perhaps using {keyholder} or a similar data structure that combines tables and keys
Logic of operation
- check compatibility
- persist tables one by one, topologically sorted
- put back into dm if necessary