Select column with same name from list of mixed-type objects

I have a list that contains various object types (Property, Unit, Room).

All three corresponding tables have a column named “Class.” But when I try to print the value in that column, the formula builder seems to be choosing the “Class” column from property, so I’m getting blanks for the other two object types.

Is there any way to refer to a column indirectly (i.e. by name)? Alternative solution for my situation would be to get the table name from the object.

See: Coda Feedback

CC: @Paul_Danyliuk (this seems like something you’ve run into before)

Please make and share a dummy doc with a sample of what you are trying to do.

There are many of us that can help you, I think this is pretty basic once know how to do it.

@joost_mineur I’m a fairly competent Coda user and I don’t think this is basic, but I’d love to be corrected. It’s hopefully more clear when seen with the dummy doc.

Dummy here: Coda Feedback

Other solution, if you know how to provide it, would be to be able to get the table name for the object.

Hey Christian, I didn’t realize you were an experienced user, sorry about that. I will check your doc once i am back at my pc.

Hey Christian,

The problem with your setup is that you think that [Class] is going to be found in the proper table, but it works a bit different. Even though you see Class in all three tables, these are actually not three times the same table (look at the column ID to see that these are three completely different columns. In your formula, the currentvalue.class is only going to find a match for the fist item (because that’s the [class] you have in your formula - the other items (2nd and 3rd) don’t exist in the first table and that’s why you don’t get any return.
The solution is rather simple - you need one master table with all items (collapsed in my sample) and three views. You can take the first item of each view and do a currentvalue.class and it works, because in this setup the class column in the master and the three views is the same table and it will find a match.
I made a sample for you - it looks identical to yours, but is quite different.
Copy my copy of your doc to see how it works: Copy of Coda Feedback


1 Like

Hi Joost - thanks for your suggestion but that’s not going to work in my use-case. I have three distinct tables because they represent three wildly different kids of data. In the real-world version these tables have very different kinds of data.

In other words, in an object-oriented paradigm these objects are three different classes, but all of the classes have one property in common – the Class.

While most programming languages interpret the syntax at execution time, Coda does some syntax interpretation (and more importantly, translation and masking) within the editor – so when I use the dot operator to seek the Class property, it’s already decided that it’s only looking for the Class property as it’s defined in the Property table.

I could have a massively large table, but I have other solutions that are better than that already. What I’m hoping for is a way to simplify my syntax.

Hence my question: is there a way to refer to the column indirectly (by name) instead of having the editor/interpreter pre-determine that I mean a column from a specific table?

I’m not at a computer but if I’m getting it right, you want to refer to “Class” column from a table that’s somehow selected earlier in a formula?

You cannot do that. The moment you type in TableName.ColumnName (or just ColumnName and then select one from the suggestions list or let Coda guess one for you) it is saved to the formula as quite specifically TableID / ColumnID pair.

If you have conditional logic (e.g. if this then update Class from Table A, else from Table B etc) you currently have no other viable option than make it into a SwitchIf/Switch and type your ModifyRows three times with a different setup for each table.

Speaking OOP, Coda does not have inheritance, so three Class properties from the three classes of data are, well, three properties declared on each class individually, not on an interface or a superclass. So technically speaking, those are not common at all and you cannot reference them in a common way.


Hello Christian,
Like Paul is saying in this thread, I don’t think it can work the way you would like for this to work.