Are there plans to remove the one sync table per document limitation? I know the current workaround is to have multiple sync settings, then filter records through the rest of the app, but this does not seem scalable when building a doc that will use many syncs (e.g. ~1,000 different sync settings per year)
2 Likes
I didn’t know that this is a limitation, I thought multiple syncs are only offered in Team and above plans. Yes, it is quite frustrating.
1 Like
I don’t understand what you mean. I never had problems with that.
Can you please give a specific use case?
1 Like
Let’s say I run 500 marketing campaigns every year and I want to sync with the Twitter API to pull in tweets with a specific hash tag
I feel like the workaround is to create a new document for each campaign, but this feels clunky, and the limit of one sync table per document seems arbitrary
Documented here:
1 Like
He’s talking about the fact that you can only have one sync table per pack in a doc.
So you can’t create two separate Messages packs in the same doc from the Gmail pack
You can’t create two separate Calendar tables in a single doc from the Gcal pack
You can’t create two separate Airtable sync tables from the Airtable lite pack.
It was originally designed that way to prevent overload on Codas servers, but now I know there are thoughts about re-structuring how packs works to allow for use cases like this due to all the new use cases springing up
For now your only option is to “add another sync” manually
1 Like
I’m trying to get around this limitation by creating an Action that calls out to the External API, and then manually upserts records into the Coda table - however this is currently not possible:
pack.addNetworkDomain("external.com");
pack.addNetworkDomain("coda.io");
It just seems as though anything I try to do with Coda, I am constantly coming up against barriers. My use case is not very advanced, in fact I’d consider this a very basic use case - import data from an External API in a way that scales… not “Jam thousands of records into a single table”… and yet, even though scalability should be achievable for all makers, it is outside the grasp of Coda’s capabilities it seems
1 Like
Yeah, guessed so but wanted to ask just in case.
I don’t think so — how would it load the servers differently than multiple syncs per one sync table?
I think the reason is the data design one. In case of Messages in the GMail pack, for instance — there’s the concept of Message, and one concept belongs on one table. It is bad practice to have separate tables for e.g. Starred Messages, Important Messages, Messages with Tag 1 etc. Hence the common table and multiple syncs. It is one model, and whether a message is tagged, starred etc is a property of a Message, not an entirely different type of data.
Airtable Lite pack is a different story because it’s a custom pack. If it allows only one Airtable sync table then it’s the pack author’s choice and it doesn’t mean it’s the right one. Maybe the author wanted to publish a pack asap but didn’t yet know how to work with dynamic sync tables. Maybe there wasn’t a dynamic schema feature back at the moment. Or maybe the author consciously wanted to make a limited “lite” pack to then upsell to the paid “pro” pack. Or maybe all of the three.
I’m also not sure if @mattfysh means this limitations when using packs made by others (in that case the answer is above), or is it a problem they experienced building their own pack (since this category Making Packs is for those who make custom packs, and Ask the Community is for consumers). If you’re a pack maker and you want to enable multiple instances of a certain table (read: consciously treat those instances as completely different entities, e.g. Airtable syncs of tables Tasks and Projects are definitely two different concepts), there is a capability to make Dynamic Sync Tables that allows just that.
1 Like
@mattfysh — the Twitter API pack is the one made by Coda or the one made by you? I honestly don’t know as I never used it.
If made by Coda — perhaps the reason for this choice was that most people would want to effortlessly import tweets with some criteria just like emails. Very few would need that vast variability of criteria (2-3 at max) and most cases would actually be solved with a single sync table and multiple syncs.
If that’s limiting, you can build your own pack for the Twitter API and implement it in a way where each search query (tag or whatever) would result in a separate sync table through a different dynamic URL.
But before you do that, think if you really want to import those as separate concepts. Because if you have e.g. a table of Clients and you want to lookup tweets related to each client, remember that a Lookup column can only link to row(s) from one table.
1 Like
I have provided a clear example where the existing solution does not scale - unless you believe that jamming tens of thousands of tweets into a single UI-rendered table is scalable?
I haven’t yet brought pagination into this discussion (I created a different thread for that), and I can already see that there is no appetite for increasing sync table complexity in order to address scalability concerns.
For this reason, I will abandon building the Pack, and rather use the Coda API as an export destination for my users only. This is unfortunate, as I was hoping to offer my Pack to all Coda makers to import web data into their docs from my APIs, unfortunately the Coda platform is has not reached the level of maturity required to deliver such an integration.
Would you jam “tens of thousands” of tweets into a single Sheet / Excel file?
Nobody said Coda was scalable. On the contrary, it’s a doc and it should be treated as if it were a doc, not an ever-expanding database. It’s easy to forget behind the “it’s in cloud and everything magically works” argument that in the end all is tech and tech has limitations.
If you want to get tens of thousands of tweets into a single doc, then probably you should reconsider the architecture altogether. Do you need to actively calculate on all of the tens of thousands with real time formulas? Or will it only be a portion of data that a person interacts with? You say you run 500 marketing campaigns — IMO in your context it makes sense to have one doc per campaign or one doc per client, one master doc for overall tracking, and cross-doc connections in place (e.g. with my upcoming Advanced Doc Connections pack)
Coda is not just a doc - it’s a no code app builder, as evidenced by all the features provided
1 Like
I feedbacked this in the beta and as I understood main reason is data design and creating lookups. I thought it should be as easy as duplicating a table, but it seems it is not.
I think it would be very cool to have the option for same tables multiple times. Some APIs have filters on API level. If you want to have that in Coda you would need to provide a sync table for every scenario to allow users multiple data views. As a workaraound in a FB api test pack I just offered the same sync table with the same options multiple times on pack level.
But nothing you want to have in a clean app you share with others.
I know the author of the pack and helped build parts of it
The author has definitely written many dynamic sync tables, Airtable lite exists this way now due to Airtable’s limitations in their API and limiting access to their metadata API until fully launching OAuth2 support.
So I do stand by their being use cases for multiple syncs of a table within a doc! It is an important feature in a few cases
This misconception is perhaps the #1 reason why people get enchanted and disenchanted with Coda.
Sorry, but it is a doc, not a no code app builder. Telling this as one of the top Coda advocates. You can build docs as powerful as apps, but those are still docs.
1 Like
Good word here. Powerful powerful docs, as powerful as an app.
But docs
I don’t understand the mentality of “Those issues will not be addressed because Coda is just a doc”
First of all, high cardinality in sheets is a feature of most docs so there are always scalability concerns to be addressed - hence limits well beyond 10K rows, and the use of virtualized rendering in the UI to display tables. You could say neither of these features should have been built if Coda were “just a doc”
Secondly, it results in so many instances of over-promising and under-delivering. Look at the existing Pack offerings and you will find quick & easy ways to introduce scalability and performance tensions with most of them. e.g. the Twitter pack (when it actually works and doesn’t throw 400 errors) can result in the syncing of many tweets to a doc, and provided with no asterisk or fine print – no wonder people can so quickly become “disenchanted” with Coda.
It’s a testament to Coda’s inflexibility that these barriers appear often and early, which can be discouraging. But - it is much worse when you come to this community to highlight valid use cases and reproducible issues, only to be stonewalled. I have noticed over this past year that hiding behind “it’s just a doc” seems to be done on a whim… and arbitrarily so
So I reject “it’s just a doc” because that excuse is just not good enough.
3 Likes
Hi @mattfysh - I’m a bit late to the conversation (was on a camping trip for the last few days), but thought I’d add some additional information and/or options.
Are there plans to remove the one sync table per document limitation?
At the moment, no. It’s a pretty constant point of friction for folks using Packs, so it may be something we address in the future, but transparently it’s not something we’re actively working on. And to clarify, the core reason for this limitation isn’t scale, but rather the complexities that arise when a row with the same ID is present in two different tables and how that interacts with other features of Coda.
I’m trying to get around this limitation by creating an Action that calls out to the External API, and then manually upserts records into the Coda table - however this is currently not possible
As someone who’s written a lot of Apps Script in the past to do the same thing, I understand how this limitation can be frustrating. Packs are certainly less like a scripting language, and more of a plugin platform. This limitation on network domains exists to improve the security and trust of Packs, since users know that they can’t be siphoning your data from one system into another.
However I think you could accomplish something close to what you want by moving the logic that writes values to the table out of the Pack and into the Coda formula language itself. For example, here’s formula for a button that looks up my upcoming events using the Calendar Pack and adds them to a table:
RunActions(
[Google Calendar]::Events([ekoleda@coda.io])
.FormulaMap(
AddRow(
Table,
Table.Summary, CurrentValue.Summary,
Table.Description, CurrentValue.Description,
Table.Id, CurrentValue.Id
)
)
)
The Twitter Pack currently only seems to provide sync tables, but if it had a formula that returned the tweets you could use a similar pattern. You’d have to reach out to the Pack maker to ask them to build such a formula, or if you are building your own Pack then you already know the Pack maker well 
The formula doesn’t need to be an action, since it isn’t modifying anything directly, just returning data used by the AddRow() action.
I’d be happy to dive deeper into your particular use case and where Packs could fit in if you’d like. If you’re interested you can book some time with me during office hours.
4 Likes
Good news!
Thanks to one of the recently introduced features in the Packs SDK that allows users to manually enter a url, you can now sync multiple Airtable tables or views in the same Coda doc 
2 Likes
The underlying architecture feels like an app builder. You can really build complex stuff and is very reliable.