Feedback requested: How would you build reverse lookups in Coda?

:wave: Hi! I’m Ramesh, a PM at Coda.

Thanks for sharing this feedback - the good news is we are opening a new beta for a new linked relationships feature (aka bi-directional lookups), that make things like setting up Projects + Tasks, Recipes + Ingredients easier. The following is changing:

  • We are renaming the Lookup column type and canvas control to Relation.
  • We are adding a new column type called Linked Relation that represents the other side of this relationship
  • When you add a new Relation column, a Linked Relation column is created automatically
  • Editing is enabled on both sides by default
  • Existing “Reverse Lookup” columns added via the “Referenced by” menu option will be auto updated to Linked Relation with editing enabled

We’d love to have you try this out and get your feedback. If you’re interested, please fill out this form and see this page for other betas that we are running.

Please note that signing up for beta access to this feature will enable it only for you and your docs in your workspace (both existing and new).

Linked Relationships - Projects and Tasks

4 Likes

Oh my gosh this is amazing news!!! This is huge for me!!! Signing up right now :smile:

It would be great if this feature could be turned on or off on a column by column basis rather than automatically creating the linked relation column. In Airtable, these ‘reverse lookup’/relation columns are a nightmare; and if you don’t need them for a particular application/table, they just clutter up the table and confuse users.

2 Likes

The Coda is team is on a bit of a roll with Betas these days and I’m loving it !

I am very excited about this and will follow up with thorough feedback as soon as I get my hands on it.
Something that immediately jumps to my eyes and that I think need saddressing is:

Editing is enabled on both sides by default

In 80% of my use cases, I only wish to be able to edit on one side, but I appreciate if a read-only column is created on the other side that can be referenced in formulas etc. I now achieve this using a Filter() formula, which seems to substantially slow down large docs.

Or…does this mean that we will have a way to disable editing on one of the sides if desired ?

A more general and powerful way to give this choice to the maker would be to allow us to disable editing on a column by column basis and using a formula - a suggestion which I would like to shamelessly plug here, since the PM gods at Coda are probably reading this thread :wink: :

2 Likes

PSA (now that I played around with this Beta): Here be dragons!

Enabling this beta will make any Lookup column that is set via formula* editable!
It does not matter if it was created before or after you joined the beta. You will no longer have a way to have a one way relationship!

I can only hope that this is a quirk that will be worked out eventually. The current implementation breaks an implicit but very important contract between the maker and coda: A column can either be set via formula, or user editable - but not both.

The current Linked relation column type is always both set by formula and editable, and there is no way to opt for just the old way as far as I can see. This has resulted is quite a few of our views breaking, with columns that were intended to just display rows from another table - suddenly becoming open for everyone to edit.

*e.g. a column in table Projects set to = Tasks.Filter(Project = ThisRow)

1 Like

I’ve playing around with the new feature. At least, for me, it works really fine. If you don’t want the column to be editable, all you need to do is to change the type from “Linked Relation” to “Text”.

Yes the linked relation is created automatically by default. I guess they believe most people will need it than not need it. It does slow down large docs but you can anytime delete the column.

The problem is not so much creating the linked relation column by default, as much as it is turning existing lookup columns set by formula into editable columns.
It is often intentional to have such columns be read-only, and often they are created to be displayed in one view (for some users who have no business editing it) and not in another.

And no, changing the type from “Linked Relation” to “Text” is not sufficient because

  1. I have 100s of tables in dozens of docs across our company workspace that have lookup columns set by a formula. Do I now need to go and hunt for all these unwanted changes and ‘fix’ them ?
    and :
  2. the generic ‘Text’ format loses you all the downstream niceties of having the column recognized by coda as being a lookup column, such as formula auto-completion , formatting, etc.
2 Likes

Actually, to make the Linked Relation field non-editable, you can just edit the pre-written Filter() formula and add either .First() or .ListCombine() (depending on if the field is meant to be a single select or a multi select) :innocent:.

At least, this has been working for me since I got access to the beta :blush:

I didn’t see this honestly :thinking: .

In my older docs, my now Relation/Linked relation fields are still as I set them up initially… Well, it looks like it, from what I can remember :innocent: .
(I.e.: my editable relation fields are still editable and my non-editable linked relation fields are still non-editable)

3 Likes

Interesting. I have definitely checked many tables in many docs, and anywhere there was a simple Table.Filter() formula, it had turned automatically into an editable column. I have since withdrawn from the beta, so cannot check again. There is a chance that Codans changed this behaviour in the meanwhile, which would be a step in the right direction!

Good trick! But in my opinion this is a bit brittle, as it relies on a current interpretation of what formula-set columns will remain uneditable, and what formula-set columns are now magically deemed editable! So if coda’s rules change, we will be on the hunt again to fix our docs.

Once we unleash the “columns-set-by-formulas-can-magically-become-editable” dragon, there will be no end in sight to these doc-wide bug hunts. This will bring coda one step closer to Excel (where any formula anywhere can be overridden by a fixed values), and that, imho, would be a step in the wrong direction.

3 Likes

This is indeed entirely possible :blush: !
I didn’t check each and every doc I have when the beta launched so you could be perfectly right here :blush: !

Yes, I agree here :blush: .
In the first feedback I sent regarding this beta, I suggested to have a toggle to enable/disable the editable feature of the relation/linked relation field (regardless of the formula used).
I don’t know if it’s a good idea or not but I thought that at least, this would help makers to be in control of their relation/linked relation fields again without having to deal with formulas.

As for the rest, only future will tell :blush: .

2 Likes