The Merge Table pack enables merging and syncing multiple tables across docs into one combined sync table. Similar to the Cross-doc pack, but with the added benefit of being able to pull in rows from multiple tables at once to merge their values under common columns!
Useful for combining multiple tables that share common columns, for example merging Tasks, Meetings, and Projects tables into a single Calendar layout table showing the names, type, and relevant dates for each.
See the pack listing for more details and documentation.
See this community thread that details some of the motivation behind this pack, as well as a more technical discussion of the design decisions behind this approach.
The currently released Lite version is limited to a single merge table per doc and merge tables are limited to merging two source tables from the current doc. The Pro version is already finished but not yet released. Stay tuned!
Rows are populated according to the natural sort ordering that the rows appear in the specified table (or table view) in the doc. Note that the order in which tables included in the merge will have their rows populated into the merge table is not defined.
This pack reads the schemas (i.e. the column names and types) of the tables included in the merge to determine the schema of the resulting merge table. It does so in a deterministic way according to the following strategy:
- Group together all columns with the same (normalized) name
- Depending on whether the column merge is “union” or “intersection”, keep all columns groups or discard the groups where the columns are not common to every table, respectively
- Resolve each column group to the most specific type encompassing the types of all columns in the group*, falling back to the Text type
*this step is somewhat opinionated, as the value types available for pack schemas as well as the type formats used by Coda do not expose any specific hierarchy (nor do they exactly map against each other). The hierarchy used is chosen to mimic the expectations for how types resolve across various end-user systems in Coda, such as the Coda Formula Language. For more details about the resolution hierarchy please contact the developer.
There are a few special columns that are always included in the resulting merge table, representing metadata to keep track of where the rows were taken from. These columns will override any same-named columns in the tables to be merged.
Row URLis an absolute link to that row in its source table
Tableis the name of that row’s source table, which can be used to discriminate the row’s provenance
Although it would be possible to enable configuring individually whether hidden rows and/or hidden columns should be included in the merge, currently the Coda API only allows for an “all-or-nothing” approach (see this community thread). This means that in order to support the more common use case of enabling table views to be used in the merge to filter hidden rows from their “parent” tables before the merge, we cannot support including merging hidden columns.
Including hidden columns in the merge would be desirable to allow for adapting certain table columns to the merge, in a hidden way. For example, with a Projects table with a “Deadline” column, and a Meetings Table with a “Date” column, clearly the intent would be to merge both tables on the common Date type column. However, they cannot be merged unless their names match. The workaround is to create an “adapter” column in one or both tables with a common name that simply copies the respective column from either table. In this example, that could mean simply adding a column named “Date” to the Projects table, whose formula would be
[Projects].Deadline (simply a copy.) With this, the tables can be merged as expected onto a common “Date” column. However, this requires that the “Date” column not be hidden in either of the tables.
An alternative would be to instead merge the tables columns with the
"union" operation, which would copy over both the “Deadline” and “Date” columns into the merge table in the above example, and deal with merging them manually in the merge table with some additional formula column. This keeps your source tables lean, but adds overhead in computing the common column manually in the merge table.