This is pretty much it, it would be useful to be able to use the very name of a table as a variable in a formula.
The use case leading me to propose this feature
I have tables each named a year (for instance : 2021). Each table has the same logic.
Each table features columns using “ToDate” to fill all rows with the 1st day of January, and last day of December.
I populate all the cells with a formula like this : ToDate(“2021-01-01”) / ToDate(“2021-12-31”)
I would like to be able to write something like : ToDate(Concatenate([TableNameWhichIsAYear4DigitNumber], “-01-01”)) so that when I duplicate my table for a new year, this automagically takes into account the name of the new table (2022, 2023, …) to populate the cells…
Note : These values are then used in the formula of another column to compute the month corresponding to a week number (the rows in the table are going from 1 all the way to 52 : numbers of week, as plain numbers, no formula. But of course, depending on the year, a week can be in this or that month. [And the complex formula that computes what month, in the given year, corresponds to what week number, performs a Sequence from 1st January to 31st December](How to get the corresponding month name from a weeknumber? : How to get the corresponding month name from a weeknumber? - #5 by Christiaan_Huizer), so there is the need for both columns with both dates.
Can I ask why you have different tables by year? Your setup sounds un-Coda-ish to me.
Whenever you have multiple tables with the same formulas/columns/logic, you should ask yourself if they can be combined into a single table (and then, if you’d like, you can create different filtered views of that primary table - for example a 2021 view with a filter of Date >= 2021-01-01 AND Date <= 2021-12-31)
I have this same issue now and I think I can give a clear explanation - In my case I want to manage events (which will be in one table) and event attendees, which would presumably all be in one another table. But the event attendees can run into the thousands per event, and thus before long I would be over, what I understand to be, the 10k soft limit for number of rows and heading for performance issues.
So I would then use a table of event attendees per event, and to pull the event attendees into the a field in the event table I need to reference each event attendee table as a variable in a field in the events table, and then use it in a formula in another field on that table to get all the attendees.
I did actually just find a workaround that I think should work depending on the application. In canvas columns you can enter a formula on the canvas and this can be different for each cell. Thus each cell will have the same formula with the table being referenced being different for each one. And then you can you the result from that as required in additional fields on that table or elsewhere
It is my understanding that the ‘soft’ limit is not so much per table, but for a document. 10 tables with 3K rows each would probably kill performance. I am not a 100% sure about this, but that’s my current understanding.
I have run into performance issues with 20K rows in a table, but I have to do some new testing, because performance is improving continuously and I think that even the row limit might increase over time. You also have to keep an eye on the maximum doc size, but it can be pretty big though.
That said, if you are going to store thousands of rows for each event and you want to keep all your records, Coda might not be the tool for you. If you read previous postings in the community you will see that this comes up regularly: Coda is not a database, although it can look like one, can do a lot of the same tricks (and do well and let’s you build queries quick and easy), but at the end of the day it’s a doc with tables with a finite row (records) count.
Thanks Joost for the insights that is helpful - I am already beyond that in total row count for my main doc and performance is still fine, but I am making plans to carve it up to get those down to within the range you state.
Indeed generally I am trying to work out when to use Coda and when I’m going to run into issues before long if I do so
