I keep running into a roadblock on a project, and it always comes down to the same thing: I need an NxM table to be generated automatically (variable N and M), and I can add/delete rows using Actions to solve one dimension but I can’t add/delete columns using Actions to solve the other.
It would also be really useful to be able to RunAction(xxx, n times). If I want to add ten rows to a table, this would be timesaving. If I want to “add as many rows to this table as there were in that table” then it becomes close to essential.
Regarding AddColumns(), if you feel like you need that you must be doing something wrong. Coda is not spreadsheets, you don’t think of your tables as MxN matrices in Coda. Columns are not a dimension of data here — they are properties of records, which exist one per row. Think of Coda tables as if each row in Coda is a cell in Sheets that can hold not one but multiple values (multiple characteristics of a record).
What you most likely need is a table that would have MxN rows, a column to store the group value on M dimension, and a column to store the group value on N dimension. And a column to hold the value. If you disagree, please tell me what you’re trying to achieve.
Regarding RunActionsN(), there’s no need — you can implement it like this:
Also you may find this tutorial useful (the first ~10 minutes of the video):
P.S. There is only one truly valid reason to want an MxN matrix in Coda: for copy-pasting it into existing Sheets that expect this kind of data orientation. Unfortunately there’s no good solution for that: you either need to update your sheets to accept a vertical table, or deal with the fact that you can only have a constant number of columns and spend quite some effort setting those up.
@Paul_Danyliuk, thanks so much for the Sequence solution, that is so much help! I have a bunch of uses for that!
I understand why what I wrote looked like “spreadsheet-think.” I HOPE that is not what I am doing. Here is the use case: I have my planning table where I put together multi-step projects, I wish to distribute instances of those to a group of users and keep track of their work on their instance of the table. Suppose their work affects 3 columns, 10 rows. Each row is a task, the three columns data on their individual progress on that task.
So I can track their progress on a table that has four columns, one additional one for “user,” and make a table that has 10 x (number of users) rows. I don’t want that to just be the same table I am planning with, because it has many, many more columns and a whole bunch of logic in them that I don’t want to overburden the system with. So I want a distinct “status” table. (There are other reasons for this too, but I don’t want to bore you!)
So far so good. But now, suppose I add another column for users to the planning document. I need to be able to add another column to the status table. I can do that by hand, but the goal is to set this up so that people can use the planning document without having to know what goes on behind the scenes.
No, I am doing what you suggest already. What I am dealing with is this:
Current structure:
Task (datapoint1, datapoint2, datapoint3)
Status Table: lots of rows, five columns (task, datapoint1, datapoint2, datapoint3, user)
I can do all the filtering, grouping, etc that I want.
BUT: what if I need to add datapoint4? If it was all just one big table, then all would be fine. But I have reasons for it not being one big table but two, and I am hoping not to have to give those up. So I need a new column in two tables, and I’d like to be able to add it from one.
My current solution is to have the datapoints in a single column as a list, which works, but is pretty “heavy” in terms of the list operations needed to perform updates into a list at a certain position and the amount of work to ensure that list length and position stays where it needs to be. If that is what I need to live with, I live with it!
Ah sorry, I read your reply more thoroughly and I understand it now.
Are you adding columns that often? If not, then I don’t think just going over multiple tables and adding a column in each of them manually is a problem.
If you’re adding columns (properties) often, then perhaps you need to rethink how data is organized. Maybe instead of datapoint1, datapoint2, datapoint3 columns you actually need a separate table for that.
Finally, maybe you don’t actually need two separate tables there? and the issues you assumed to arise from using a single table are solvable in some other way?
Subtables may be a better way to go than lists, and I am thinking hard on other solutions. Basically, as you say, I should be trying as hard as I can to solve problems by making them “add rows” or “add to this data” rather than “add another dimension to the table by adding a column.”
The advice to have two tables comes from others in the community, and it may be the costs of going that route are too high.
The more complicated issue is this. What I am trying to get to is a three tier system. So there is me, architecting all the details and trying to think of all the things that can go wrong and how to make it painless. Then I hand that off to the second tier, who use it to make planning documents, who then hand it off to a third tier, who fill in the details. So I can remember to add a column to two tables, but I don’t want my second tier to have to remember.
Can you please briefly explain what made you consider using two tables?
I’m not saying it’s an invalid advice — I do this often myself, mostly to work around the behaviors of locking permissions (e.g. to prevent doc users from deleting rows in the “backend” table by only letting them modify the “frontend” table and saving with a button.) I’m just wondering if that’s the best advice for your case, or it just adds unnecessary complexity.
Here is a current version, tho there will be a lot of similar use cases. There are 15 columns in the table, but for each user I only need to track three - status, actual start, actual end. And I have many of the same issues with control over what is editable, what should not be editable.
Sorry, I still don’t understand why you’d need two separate tables. In your example I see Task Planning and Task Management — but those are two views of the same table. Columns that you add to a base table or either view will be available in the base table and all views, hidden by default.
Yeah, they are just two views of one table. You aren’t missing anything.
I am working on the actual multi-user version as we speak. The way it is supposed to work is that one person ( a teacher) fills out the details of how they want to sequence the project. Then you have (potentially) HUNDREDS of distinct users (students) who would be using the project tracker with their own statuses, start dates, end dates. I could do this by simply having one more column (student) and filtering, but then my table is 15 columns wide by 1600 or more deep. And most of that is redundant, because there is only three columns of actually important info.
I’ve barely begun working on the issue of how to control permissions. The ONLY bits of information the students should be able to change are those three columns.
Yeah, having a separate table for student-task level is a right way to go here.
Regarding columns, yeah, I guess you’ll just have to do any schema changes by hand. I don’t think you’d have much benefit in adding columns automatically though.
Think of it this way. You’re the doc maker, and the lower tiers are doc users. Your responsibility is to design the doc in such way that 1) for users it’s obvious how to use it, and 2) they never have to (and never can) touch the setup and the schema. So ideally your teachers never have to e.g. set up the filters and sorting themselves (instead you’ll give them external controls for that), and they never can add columns themselves — all these changes should come through you.
