If I change the name of one of the items (say I realize that I wrote Cumin but I meant to write Curry) then when I change the value in my original Ingredients table it breaks the Recipes table.
Now my Recipes table is broken, so I have to update the ingredient column in Curry Chicken Recipe Ingredients column.
If I made the mistake in many locations then I have a lot to fix. It would be nice if when the contents of the row is updated the table is automatically updated as well. Perhaps this could be done by referencing the row number rather than the actual ingredient name.
Note: This is obviously a bit of a contrived example, but work with me.
Another Note: I think the right way to do this would be to put it all in a single table (I seem to fail to do this every time) so I recognize that this could be my own shortcomings, not a Coda issue. But it is something that I run into fairly frequently, and it is a current pain-point that I have with several documents that I’ve built. Again, perhaps I could migrate all my columns into a single table and that would fix the issue, but for my current design methodology it’s problematic.
What type of column is “Ingredient”? If you use a “Lookup from table” type and set the “Total” column to the formula: “Ingredient.Cost*Quantity” then your data should stay consistent.
Yup, Lloyd has the right solution! If you have the select list contain references (by referencing the whole table in your formula) instead of just a list of strings, then that list should stay consistent even if you rename any ingredients.
So under what circumstances would I want to use a “Select List” instead of a “Lookup from Table”? It seems like I would always want that updating property, right?
Edit: Thinking about it more, even when I would define my own select list options, I probably want them to stay consistent if I ever update them. E.g. I manually put Cumin, Parsley, and Chicken in the Select List dropdown in my table, if I ever changed them wouldn’t I want the ingredients that are referenced to change as well?
Really only if it’s a simple list of things that you don’t think will change, for which it’s not worth creating a table. Things like statuses, categories, etc. as opposed to concrete things like ingredients, people, recipes, and so on.
It seems that Select Lists pulling from existing tables should act like a Lookup from Table with a Unique() filter applied to the selection options, that way the contents can update dynamically when names change. You have no idea how much time I spent renaming contents of various tables before I discovered I could use Lookup Tables (which still are giving me the repeat item issue).
It’s not really giving you the option to pull from a table per se, it’s just giving you the option to programmatically define your list, and so you’re given a formula box where you can decide how to build your list.
For example, you could have your list just be the next few days using the formula =List(Today(), Today() +1, Today() + 2). If you tried to maintain a table of this, you’d be running in to trouble.
However, one of the side effects of using formulae to define lists is that tables are an integral part of Coda formulae, so you can’t just deny people the option to use them because it might make more sense to do it with lookups instead.
There are other reasons that you might want a list of strings from a table rather than row references, but mostly these are more complex.
+1 to @Joe_Innes’s comment. Select lists let you define the available options using a formula, and that formula can be a table if you want it to be (though you should probably use a Lookup column in that case).
Formulas for select lists are still pretty useful, like if you want the selectable options to be based on another value in that row or if you want to generate them programmatically. For instance, instead of typing out numbers 1-30 you can just write Sequence(1, 30).
