Optional Input Variable On Update Action Where Clause

On our radar
It would be nice to have an optional parameter to Entity UpdateAction to be used on the where clause besides the id.


Update ..... Where id = Y and updatedat = Z

This  will make possible to control duplicates more easily.

Created on 25 Oct 2010
Comments (9)
Not sure what you mean.

The id is unique for that entity, so why the extra parameter?

The purpose is to guarantee that you are updating the correct record and not one that has been changed between the get and the update.

I think this is the easiest way to acomplish.
Erm, sorry.

Can you give an example with what you mean?

Do you mean, that an Id is not unique in this case(?)
Imagine this:

Two users are viewing the same database record.

When you get the record from the database you get the lastupdatedat.

When trying to save the update will use the record id and the lastupdatedat that was retrived at screen preparation in the where clause of the update statement.

The first user will update correctly, the second will have an error message showing that the record has changed in between.

Without locking records

Makes sense?
Ah, I understand now. thanks for explaining.

However, yes there is always a but!

Why not use GetForUpdate  action to lock the record?
Because the GetforUpdate with lock the database record and this way i won't  need that
Having the ability to specify an attribute of the entity (for example  LastUpdateDateTime) that would then insert a where clause (my.LastUpdateDateTime = db.LastUpdateDateTime) and throw not found exception if no match would solve the issue. Obviously, the developer would be responsible to set the LastUpdateDateTime in the cached copy before update. This would be a very simple solution for optimistic locking. 

A more advanced solution would be to allow you to specify the Optimistic Locking column on the entity definition and have this behavior happen automatically throughout the sysem. 

Note this would also be needed on the CreateOrUpdate action as well (but only for updates). 
@Rodrigo: why don't you want a lock on a record? The usual sequence would be getforupdate -> change data -> update, which'll take only a split second to run.
New to OutSystems and this is an old petered out thread, but this is exactly what I am looking for rather than using the entity encapsualtion pattern. Never want to do a GetForUpdate because if something fails those locked records can be hard to deal with.