15 min read
Replacing tables with connected views
How to retrofit an existing doc with connected views.
What you'll learn:
- How to identify tables that could be views.
- How to efficiently replace tables with views without data loss.
- Change management best practices.
What you'll use:
- Tables and views
- Doc explorer pack
Watch a detailed CSM walkthrough
1. Compile a list of tables you want to connect.
Tables that would make good connected views are the ones that share a common noun. Learn more about deciding if a table should be a view here. Consider using the Doc Explorer Pack to quickly pull a list of all tables in your doc. Add a checkbox column to mark which tables you plan to turn into connected views. Once you’re confident you’ve checked off all the tables to combine, add a table filter to show only the rows you’ve checked off.2. Create a new base table.
This will be the new table where all the rows from all the separate tables will be added. Your new views will be views of this table. It’s best practice to store this main table in a “backend” page. No one will actually see/use this table, it will only be used to create views from. Add ALL columns that appear on ANY of the tables you’re looking to combine. It’s ok if only one table has a column and all the others do not; add it anyways. We’ll talk about hiding irrelevant columns in a later step.3. Create a tagging/filtering plan.
Each of your views is going to be a filtered version of your main table. This means you need to figure out what parameters you’re going to filter on to pull the desired rows for each view. A simple plan could be to explicitly state which views a row should appear in via a select list column. The select list options would be the name of every view you plan to make. For each row, select the views you want the row to appear in. In each view, you’d filter for rows that have that view listed. This is by no means the only way to approach this, so do what feels right for you and your doc! Check out this guide for a deep dive into how to create a custom tagging/filtering system.4. Create the views.
Go through your list of tables, and create a view of your new base table for each one. Make sure to add a descriptive title to each one. If you want your title to be the same as the original table, consider appending the original table’s title with “-original”, as all tables and views in Coda must all have unique names. For each view you create, apply the appropriate filter based off your plan from step 3. Hide any columns that are not needed for each particular view.5. Add your rows.
Going view by view, copy the rows from your original table to the new view.
Coda tip
If the columns in your view are in the same order as your original table, you can bulk select all rows/columns and paste everything at the same time.
6. Check for duplicate rows.
Return to your main table and check for any duplicate rows. Duplicate rows can occur if you had a row listed in two or more tables. If you find duplicates, select one row to keep, and adjust the column values to ensure it appears on all of the correct views, per your filtering system. Then, delete the other rows.7. Delete the original tables.
Compare each view to it’s original table. Once you are satisfied that all the rows are there, delete the original.Replacing tables in high traffic docs.
Replacing tables with views in a frequently used doc can be a challenge logistically. Here are some tips to make the transition smoother.Coda tip
Wondering how to see doc traffic stats? Learn how here.
Do steps 1-4 discreetly.
Create a hidden page in the doc where you create the new base table and all of the new views. Because the page is hidden, these new tables/views won’t impact or confuse the users who are using the original tables.Freeze operations for the final steps.
When you begin adding rows to the new views, you need to avoid users adding/updating data in the original tables that you’ve already copied over as this can result in data loss. Plan and communicate a cutover date for when users stop adding new data to old tables. During the cutover period, users will cease making changes to table content. You then can move the new views from hidden page to their live pages and complete the row transfers, steps 5-7. When all original tables have been deleted, relaunch to your team. Check out this guide for a deep dive into making the transition smooth and minimizing disruptions in workflow.Was this helpful?
YesNo