Skip to Content (Press Enter)
Training
Training
Online Training
Developer Schools
Boot Camps
Certifications
Tech Talks
Documentation
Documentation
Overview
ODC
O11
Forums
Forge
Get Involved
Get Involved
Home
Jobs
Ideas
Members
Mentorship
User Groups
Platform
Platform
ODC
O11
Platforms
OutSystems.com
Personal Edition
Community
Resources
Support
Search in OutSystems
Log in
Get Started
Back to Ideas
16
Like
Follow Idea
Rodrigo Catarino
Optional Input Variable On Update Action Where Clause
1225
Views
9
Comments
On our Radar
Backend
It would be nice to have an optional parameter to Entity UpdateAction to be used on the where clause besides the id.
Example:
Update ..... Where id = Y and updatedat = Z
This will make possible to control duplicates more easily.
Thanks
RC
J.
MVP
Not sure what you mean.
The id is unique for that entity, so why the extra parameter?
Rodrigo Catarino
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.
MVP
Erm, sorry.
Can you give an example with what you mean?
Do you mean, that an Id is not unique in this case(?)
Rodrigo Catarino
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?
RC
J.
MVP
Ah, I understand now. thanks for explaining.
However, yes there is always a but!
Why not use GetForUpdate action to lock the record?
Rodrigo Catarino
Because the GetforUpdate with lock the database record and this way i won't need that
Greg Berger
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 Hekhuis
MVP
@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 Matthews
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.
Log in to comment
Loading...