Check out
to see the bug in action.
Essentially, I would like to have the Due date be automatically calculated when I create a new row, but for some reason nothing is showing up.
Yes, should now be shared! I thought published docs would be editable when I selected the Edit option
Hi @Connor_McCormick,
actually, I can just play with it…
There are two ways:
- you allow to see the copy button in the the doc when you publish it
- you embed your doc here in the post (in the share button, you can see the embed tab). In this case, obviously permissions should be put to edit, as well.
Thank you.
Ok, copy button also enabled 
I think I got the point.
Please: have a look at the modified example:
Basically, you added a default value to a column of a row that wasn’t yet created.
In order to make it work you can:
- (as I did) retrieve from Meeting History table the Meeting with the Created Date (is is a property that exists, in the row creation)
- you change the Due Date with a formula (doable only if you don’t have to edit it).
Also, I did some slight modification in the Meeting History table just to keep it cleaner and easy to debug: up to you to keep this approach.
Please, do let me know if it works for you.
Cheers!
So, definitely not a bug…
I’d change the category of this post.
Thank you. That’s the solution I’m using in my live doc.
Why is this not a bug and a violation of intuition?
Why can’t a row understand its operational precedence? If I had a column with the Value for new rows formula thisRow.RowId() that cell would never come up blank just because thisRow doesn’t exist yet. It understands to run the command after the row has been created. Why shouldn’t it also understand that when a formula relies on the calculated contents of a different column it should wait for the contents of that column to exist?
1 Like
Hi @Connor_McCormick,
you are right: I think I shortcut the matter and I owe you a better explanation.
Form a semantic perspective it should not considered a bug as it doesn’t violate a specific requirement or a functionality.
However, your point is correct.
[This is my personal opinion and I could be contradicted by Coda engineers]
One thing are row’s immutable properties. i.e. intrinsic row attributes that any row contains in the instantiation of the row itself. They are Unique ID, Creation Date, Creation User and - slightly different - RowID(thisRow).
Then there are row’s values (columns).
Having a default value for a creating column is pretty intuitive if it is a literal or external calculated value.
But if the value itself depends on a value of another column, it implies a dynamic evaluation dependency process in the column creation that could even leading to a circular reference of “who depends on whom”.
This is why I would not expect to work.
A simple rule of thumb might be that columns are evaluated in the order they are declared (we could have a try, btw…), but this would be a weak solution anyway.
Anyway, I think you highlighted a good point and I’ll try to dig it more deep and see if I can have some internal thoughts on this.
Thanks a lot
2 Likes
One thing are row’s immutable properties . i.e. intrinsic row attributes that any row contains in the instantiation of the row itself. They are Unique ID, Creation Date, Creation User and - slightly different - RowID(thisRow).
This is a good point but kinda misses what I was trying to say. It’s on me for coming up with a bad example. RowId(), yes, has to be instantiated as part of a row and therefore would naturally precede any formulas in that row in terms of execution time. But as you know, there are many columns of your row that are calculated and dependent on other columns. Consider a column called “Total Cost” that is calculated by way of the formula Quantity * [Price Per Unit] That clearly depends on other values in the row.
It would be quite problematic to not be able to use a formula like that if, say, “Quantity” was itself calculated from a formula.
Hi @Connor_McCormick,
I totally agree.
But a Formula column and its default value at instantiation are different exactly for this reason.
In fact, if you use a formula (like suggested here)
it works perfectly.
A formula “assumes” you have already created that row and you have subsequent computations among its values (columns).
A default value occurs in the creation of the row itself and might lead to the aforementioned race conditions.
I think what I’m saying is that I expected default value formulas to work like formulas.
The fact that they do not work like formulas is a violation of intuition and causes bugs in tables.
Is there a reason why we would prefer that default values have this behavior other than the fact that it’s the behavior they already have?
An alternative way to solve the problem: detect if the token thisRow is used in the default value formula, if so present a warning that “row cannot reference other default values when setting a new default value.” or the like.
Seems like I keep running into similar issues like @Connor_McCormick ! 
The perfect solutions would include “add row” buttons with “open row for editing” enabled:
- When clicking the button, all the default values for new rows that don’t refer to “thisrow” become filled into the opening form for editing.
- You can now change those default values and set other ones.
- When closing the form, the row gets added and all the default column values that refer to other columns in “thisrow” and haven’t already been set in the form become evalutated.
“Value for new rows” already allows you to reference “thisrow”, but only creates a value if you press the “apply to X blank rows”, so in a way, this action simply needs to be applied only to the new row after closing the form.
I hope I explained this in an understandable way.
So could we move this to “suggestion box” or should I create a new thread over there?
Uh @Connor_McCormick I was going to say you were wrong about RowID() because it’s NOT available right away after the row creation. Row ID gets assigned when the row is stored to the server, not necessarily immediately. However out of curiosity I tested your example and was surprised to see that thisRow.RowID() did appear to work, instantaneously filling out the value there.
That’s until I started adding rows far too quickly:
So I guess, what happened to thisRow.RowID() is that Coda decided to implement a workaround just for this [probably common] use case. Well, apparently they did it in a half-baked way by taking thisTable.RowID.Max() + 1 or something 
Now this here is a bug.
But yeah, @Federico_Stefanato is right about race conditions. You cannot reliably use Value for new rows for anything other than literal values or calculations on something that’s guaranteed to have been calculated already. If you’re trying to depend on thisTable/thisRow, there’s no guarantee that everything else would have been calculated before this formula.
1 Like
I’ve tried to achieve something similar by adding a _delay() in the Value for new rows formula. Doesn’t seem to work either.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.