In Coda, you can have a Lookup column which allows you to reference another row in the table (or in another table). This is great. It means I can add a task to a project or a sub-task to a task. But unless I’m missing something, I can’t go the other direction: I can’t assign a project to a task without going to the project and referencing the task from there—a cumbersome and tedious process. I can, of course, reverse the reference order, but then I just have the opposite problem.
In other words, if you look at the image below, you can see that you can add to a row other rows as its children, and you can display any rows that have added the row in question as its children (making it their parent), but you can’t add parents to a row. To do that, you’d have to find the parent-to-be row and add the row in question as its child. Again, cumbersome and tedious.
Notion allows you to do this right off the bat: When you set up Lookup column (or whatever their version of it is called), you choose whether this is a one-way or a two-way reference. Coda seems to only support one-way references.
Coda should support two-way references.
Is there a workaround?
This is something I’ve wracked my brains on for a long time. I would really like to not have to always choose which will be a more efficient direction: parent or child columns. Notion (a far less sophisticated tool as of this writing, at least where formulas are concerned) lets you have it both ways, and I don’t see why Coda couldn’t.
Oh yeah, well, everything can be updated with a button. I thought OP was looking for something that wouldn’t require manual steps.
A button to update linked items is a workaround indeed.
Automations aren’t super reliable. Also, setting up two automations to listen on reciprocal columns — wouldn’t they start triggering each other in loops?
Yes, in theory it recursively updates. But it’s idempotent, so doesn’t get stuck in a loop.
E.g.
If you change Table 1, it updates Table 2.
Now, Table 2 is triggered to do an update on Table 1. However, it finds Table 1 already has the right contents, so it does nothing.
This still leaves you open to race conditions, given that Automations are slow, however in practice I haven’t had problems (I use this in two of my heavily used docs. Including one for a client. It’s been working fine for a month or so.)
Also, I think I made it pretty easy to implement in your own doc. @David_Knell could you try using the formula generator and let me know how it goes?
