Locking as in WorkCommit
Locking as in WorkCommit

Explanation from Paul Danyliuk on the Coda update mechanism.

with Coda it's this:

All changes come through as ops (operations). Coda once said they had ~70+ kinds of ops. I imagine things like "Add a row with columnId-value pairs" is an op, and larger edits like "modify all rows: set column1 to value1, column2 to value2 etc" are also atomic ops.

There's a constant up/downstream of ops: from your client to all editors and from each editors to all clients including you.

Coda servers apply ops in bulk once in something (a few minutes or so). That's when doc snapshots get created, automation gets triggered etc.

The ops are granular enough for Coda to have a few conflicts. In case of a conflict (both editors changed the same cell value) I imagine the one with the largest timestamp wins.

⁠

Paul Danyliuk⁠

13 days ago⁠

⁠

That's on the operations and "the source of truth" side: the source of truth is basically the latest snapshot plus a queue of ops that haven't yet been added to a snapshot

⁠

Paul Danyliuk⁠

13 days ago⁠

⁠

Now, on the doc editing side. As you've probably heard numerous times, all calculations are done on the client side. I am not 100% sure but I pretty much imagine that Coda docs have dependency graphs, and whenever a value change affects some other values (via formulas etc), those cells are marked as "dirty" and due for recalculation. There's most likely an event loop, and once there's the next frame of the loop and there are items to recalculate, recalculation happens

⁠

Paul Danyliuk⁠

13 days ago⁠

⁠

Then all the recalculated items get, again, sent to the servers as ops

⁠

Paul Danyliuk⁠

13 days ago⁠

⁠

Now with that in mind, two things can happen:

Multiple actions may be executed within the current frame — each action would change the state of the doc (aka mark some items dirty or stale) but recalculation wouldn't happen until the next frame. That's what happens when you e.g. Sequence().FormulaMap(AddRow()) things. Coda generates N addrow ops for N times AddRow ran, but this happened within the same frame so there was no recalculation between those. Oftentimes it's the preferred scenario because there's no need to wait for the rows to be added one by one if neither depends on anything that might have changed (e.g. we just add 5 rows for 5 categories that we have on another table)

Using RunActions(A1, A2, ...) will ensure that each action is placed on a separate frame and there's recalculation between actions happening

⁠

Paul Danyliuk⁠

13 days ago⁠

⁠

If you want to add a row and delete a row, you don't have any option but to use RunActions to wrap them into a single button. or RunActions also implicitly gets added when you use something like "Push buttons"

⁠

Paul Danyliuk⁠

13 days ago⁠

⁠

so you should not run into this problem at all

⁠

Paul Danyliuk⁠

13 days ago⁠

⁠

Very often people run into problems when they are using "Value for new rows" functionality on columns. If that value somehow depends on the rest of the row (e.g. there's a formula calculating row order, and there's a text field that should get populated with "Order #123" and that order number automatically on row creation, that's probably going to fail because the formula is not going to be calculated until the next frame

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

Locking as in WorkCommitLocking as in WorkCommit

Locking as in WorkCommit
Locking as in WorkCommit