Optional Input Variable On Update Action Where Clause

By Rodrigo Catarino on 25 Oct 2010
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.

J.25 Oct 2010
Not sure what you mean.

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

Rodrigo Catarino25 Oct 2010
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.
J.26 Oct 2010
Erm, sorry.

Can you give an example with what you mean?

Do you mean, that an Id is not unique in this case(?)
Rodrigo Catarino26 Oct 2010
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?
J.26 Oct 2010
Ah, I understand now. thanks for explaining.

However, yes there is always a but!

Why not use GetForUpdate  action to lock the record?
Rodrigo Catarino27 Oct 2010
Because the GetforUpdate with lock the database record and this way i won't  need that
Greg Berger14 Sep 2012
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). 
Kilian Hekhuis17 Sep 2012
@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.
Keith Matthews19 Dec 2014
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.