When dragging a Get{Entity}ForUpdate action, automatically create assign and Update{Entity}

By leonardo.fernandes on 6 Sep

I cannot think of any other use of a Get{Entity}ForUpdate, other than assigning to some attributes and then updating the entity. That requires, at least, three nodes.

My proposal is, when you drag a Get{Entity}ForUpdate to an action flow, besides creating that node, it would automatically create an empty assign node, and an Update{Entity} node with the Source referring the Get{Entity}ForUpdate.

If it is dragged to a connector, then link the incoming connector to the Get{Entity}ForUpdate, and the outgoing connector to the Update<Entity>.


I partly agree... for instance, I could want an advanced query instead.

Advanced query for updating a single record? Why would you want to do that?

I could want to eventually query something, checking if the record had been changed in the meantime, between the time the user opened the edit page and the time it actually hits a save action. But this is just one example, there are others.

In that case you wouldn't use a Get{Entity}ForUpdate. You would simply bind an edit widget to a record, and then use Update{Entity}.

Also, Get{Entity}ForUpdate locks the records, so it's impossible for another transaction to change the record before you have the chance to update it.

I really cannot think of any other usage for Get{Entity}ForUpdate without using the Update{Entity}.

I haven't said I would replace UpdateEntity with advanced query...

What happens is that once you lock the record with GetEntityForUpdate there are a number of possible business rules that you need to validate prior to actually using UpdateEntity, and, eventually, even raising an exception if those validations fail.

So, rephrasing, between GetEntityForUpdate and UpdateEntity I would frequently be using more than just an Assign.