Optimistic Locking clarification?

Questions / Help
, ,
1

Does lock_version need to be cast() into ChangeSet, or doing

changeset
|> optimistic_lock(:lock_version)

is enough?

I mean, AFAIK every attempt to update an object should have lock_version in the attributes map, so how does Ecto know what value to use for lock_version if we don’t put it into changeset by casting it?..

But when I look at examples online and in documentation all I see is ChangeSet.optimistic_lock/3 being called.

2

It just gets the field from the changeset source:

You don’t need to cast just to access the source data. And you don’t want to cast the lock version, because you don’t want the value to be set from the parameters.

3

I don’t? For the value to be set from the parameters I need to put it in a changesset somehow - I thought it’s done by “casting”. And the whole point of optimistic lock is to make sure the caller doesn’t have the stale version of the data, so it would seem like having the most recent value of lock_version in the changeset should be required to avoid the stale object error?..

4

When you call the changeset function, you pass the struct that you have, which has the lock_version value at the time you fetched it from the database. In the changeset, this original struct is under the data field. That’s where the optimistic_lock function gets the current lock version from.

Ecto.Changeset.change(%SomeStruct{lock_version: 1})

# => lock version is at changeset.data.lock_version
5

In my case I have a absinthe client that pulls the object from the backend via graphql, and edits some fields on the object. The save operation takes id of the object, the changed field, e.g. description, and lockVersion from the last time the data was pulled. Multiple users can edit the same object, hence optimistic locking to prevent overwriting someone else’s changes.
So lockVersion actually comes as part of parameters/arguments along with new value for description.
Therefore I thought the right way to do it is to

%Object{id: params.id}
|> Ecto.Changeset.cast(params.data, [:description, :lock_version])
|> Ecto.Changeset.optimistic_lock(:lock_version)

which should result in Ecto preparing a SQL statement such as
UPDATE Object SET description=?, lock_version=? WHERE id=? AND lock_version=?, and binding params.data.description into 1st arg, incremented lock_version into second arg, params.id into 3rd arg and lockVersion from the client side into the last arg. Then if updated record count returned by the database driver is 1 then update succeeded and if it’s 0 then Ecto would raise StaleStateError.

So I actually do want to set lockVersion from the params. Is that incorrect?

6

Yes, in your case, you’d want to cast the lock version indeed.