Value For New Row—Not Working Properly

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.

Hi @Connor_McCormick,
Would you please allow access to your doc?

Thanks a lot!

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:

  1. you allow to see the copy button in the the doc when you publish it
  2. 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 :slight_smile:

Hi @Connor_McCormick,

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:

  1. (as I did) retrieve from Meeting History table the Meeting with the Created Date (is is a property that exists, in the row creation)
  2. 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.

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

1 Like

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.