Doc copying super slow - anyone else?

[Nick_HE]

Making some progress which I’ll document here, in case it ends up being helpful for others.

We’ve tracked the issue down to the 20,000 image files that are stored in the doc.

This number was news to me, as it currently has no images at all in it! But it did, during building and testing, have a sync table that had a couple dozen rows with ImageAttachments in them. The table was set to hourly refresh, and I sometimes manually updated it more often than that during testing.

And each of these refreshes seems to have stored copies of every image in the doc’s edit history, which comes with a doc when you copy it (unfortunately).

So far the solution seems to be re-creating the doc from scratch, salvaging whatever non-Pack tables have lightweight enough histories to not nuke template copy performance

By the way, I think this way of approaching ImageAttachments and Attachments is bad for a few reasons which I’ve outlined here - interested to hear people’s thoughts:

Use hashes to check if sync table images and files are indeed new

I know this is a bit niche, but hear me out. Many APIs, when serving up files or images, present them as short-lived AWS links (valid for e.g. 15 minutes). When a Pack fetches from these APIs, the appropriate way to store the data is with an Attachment or ImageAttachment column type (since URL or ImageURL column types would break after 15 minutes). Often, the files/images at these endpoints aren’t actually new - but Coda doesn’t know that, because the temporary URLs are new. So Coda updates th…