Optimistic locking

[wardle]

Hi all. I'm using pathom3 to abstract across lots of different sources of data. It has been straightforward blending read-only views, but I'm now attacking the mutation side of things. One data source is PostgreSQL. One option is for me to define the mutation in terms of new values and old values, and use optimistic locking to do the UPDATE ensuring the data is as was before. That does feel as if I'm leaking an abstraction however to the client application.

How have others handled optimistic locking, or any other form of locking, in mutations?

[wilkerlucio]

Hello Mark. Pathom by itself doesn't have any locking mechanisms. One thing it does about mutations is that it runs them before running the read parts (although a mutation subquery will run before other mutations).

What kind of locking do you have in mind? Can you make an example situation to demonstrate what is lacking to achieve what you need?

[wardle]

Thanks Wilker. Essentially I have legacy data in a PostgreSQL database. If one client reads some data using pathom, and then edits that data, and then clicks save, I need to guard against someone else editing those data between the fetch and the update. The approach used in the legacy application was optimistic locking, so that the transaction would fail if the data had been changed. I could implement such an approach in the mutation - with new values and the old values - but I'm leaking the abstraction into the client. For more modern data, I will try to do something clever with websockets to avoid concurrent edits, or use an approach in which I lock on access and so prevent concurrent writes. I was interested to know any other strategies that people have used to handle concurrent record reads and updates.

[wilkerlucio]

Gotcha, this seems more like a detail of the underlying mechanism (Postgres) and from your specific system. I don't see much Pathom can do about it as a generic engine, but if you have any ideas I'm down to discuss.

[wardle]

Thanks Wilker. You are right it is not an issue for pathom directly.

I am half-way between an old world of change-in-place semantics and traditional relational databases with tables that I update and the new world of immutable data accumulating with read-only properties/graphs and operations/actions/mutations as first-class. So anything new I'm building properly, but I have to deal with legacy. But that is fine. I can make optimistic locking a way to make it safe, and it is dependent on the context and the domain how important it is for users to not clash in writing to the same record. Indeed, thinking about more, I realised it isn't something to be left as a default, but an important first-class 'thing' and if a user saves a change and someone else has edited, I can model that and feedback.

So all fine and solved - I simply send along the old with the new and do an update in which the row is updated only if the old values are still current, and send back a status.

Thank you.

Mark