Hi Isomorphic,
I always have a bad gut instinct if I set DSRequest.setAllowMultiUpdate(true) because of the things that could go wrong afterwards because of coding errors or framework bugs.
Besides setAllowMultiUpdate(true) you could also create a new method setAllowUniqueUpdate(true) that allows updates only if the top-level criteria include the isUnique validator field (+all criteriaFields) of one of the defined isUnique-validators.
In databases primaryKey-Constraint and unique-Constraint don't really differ from a logical point of view. Therefore the framework could also just add this check without introducing a new setter, but I'm pretty sure you would not like to weaken the guarantee of setAllowMultiUpdate(false).
With setAllowUniqueUpdate(true) the programmer could be sure that a request will target one row only or that the request won't execute.
This would allow me to use setAllowMultiUpdate(true) less often.
What do you think about this suggestion?
Best regards
Blama
I always have a bad gut instinct if I set DSRequest.setAllowMultiUpdate(true) because of the things that could go wrong afterwards because of coding errors or framework bugs.
Besides setAllowMultiUpdate(true) you could also create a new method setAllowUniqueUpdate(true) that allows updates only if the top-level criteria include the isUnique validator field (+all criteriaFields) of one of the defined isUnique-validators.
In databases primaryKey-Constraint and unique-Constraint don't really differ from a logical point of view. Therefore the framework could also just add this check without introducing a new setter, but I'm pretty sure you would not like to weaken the guarantee of setAllowMultiUpdate(false).
With setAllowUniqueUpdate(true) the programmer could be sure that a request will target one row only or that the request won't execute.
This would allow me to use setAllowMultiUpdate(true) less often.
What do you think about this suggestion?
Best regards
Blama