Row limits and handling intentionally deleted data when managing a large sync table (with Keep Un-Synced rows enabled)?

Hi Coda people!

I am building a doc which aggregates a list of time entries using the Toggl Track pack.

The idea here is that we will have all our staff’s time entries in one table, so we can do various kinds of custom reporting and display throughout our doc.

Keep Un-Synced Rows is enabled, so that we can pull entries from Toggl once each day and aggregate them over time.

There are two hurdles to this approach I’m wondering about:

Row Limits?

Does Coda have a limit to the number of rows that can be in a sync table?

I see a limit of 10K in the sync table options. Does anyone know if that’s a maximum for rows within the sync window or for total rows in the table (or something else)?

We may have well over 10K total rows in the table eventually with this approach, so we’ll need to make another plan if there’s a limit.

Removing Intentionally Deleted Data

Because we have Keep Un-Synced Rows enabled, we run into an issue where if someone deletes or changes an entry in Toggl, that won’t be caught by our table. I can’t find a way to remove the deleted data from the table without re-syncing, which could get expensive when we have more rows.

I don’t see a way around this since I guess Coda has no way to differentiate between data that was intentionally deleted and data which just is no longer in the sync window (though let me know if I’m missing something!).

Is there any way to manually delete specific rows from a sync table (such as with a button)?

Obviously a simple right click and delete doesn’t work for sync tables. Creating a simple “Delete Row” button for a sync also doesn’t seem to be possible, since the thisRow option is disabled for the Delete Rows action in sync tables.


Any input on these issues, or this approach in general, would be much appreciated. Thanks!

1 Like

Hey there!

Love to hear what you are doing - and I’ll just say off the bat that your goal is totally achievable, but it’s not a straightforward path and there’s a good amount of potential options.

Let’s start with some questions:

Can a sync table hold more than 10k rows?
No - Sorry. One day that might change but today is not that day

So how can I accomplish this?
Well - you will need to set up some sort of helper table - where the moment a row is synced you run and action to copy the data from the sync table to a separate table that can/will eventually grow beyond 10k

If you will need to eventually go much beyond that 10k, you’ll need to utilize a technique similar to my CSV archive technique that lets you store 10x that amount of data in a doc

How can I delete rows if someone deleted it in Toggl?
One way you can do this is by turning off the “keep un synced row” option because your sync table now only exists to port rows over to a native coda table

Then you run a comparison filter in the canvas to find the rows that are NOT in the Toggl table but ARE in the coda native table and run a daily automation to delete those rows
(Let me know if you need help with that formula and workflow)

I’ve tested this very principle with a different pack and many other scenarios/workflows just like it. Let me know if you need more context!

1 Like