Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    #76
    @Blama

    There is good news on this - we discovered and fixed another potential case where validations could be inherited incorrectly. We have posted more details on your original thread

    Comment


      #77
      claudiobosticco

      We have clarified the documentation on this issue of whether criteria should be included in values or not, and also changed the validation flow in the specific case of applyWhen validations to match this clarified position. In short, as of tomorrow's builds of 6.1 / 11.1 and 7.0 / 12.0, you do not need to include criteria in values when you are doing a regular update via primaryKey, but you do need to do so for allowMultiUpdate requests.

      Regards,
      Isomorphic Software Support

      Comment


        #78
        Originally posted by Isomorphic View Post
        In short, as of tomorrow's builds of 6.1 / 11.1 and 7.0 / 12.0, you do not need to include criteria in values when you are doing a regular update via primaryKey, but you do need to do so for allowMultiUpdate requests.
        Thanks for the clarification, I've also just read the docs.
        Actually I don't use frequently the allowMultiUpdate feature.
        If I understand correctly, those updates won't work at all if I switch to the latest build (because I've never included criteria in values).
        Will they raise an exception, or log a warning, or what else?

        Comment


          #79
          No, your updates will be unaffected; the requirement for criteria to be included in values is only about validation. For normal update requests that specify a record by its primaryKeys, we now copy the primaryKeys into the values to be validated, so you don't have to add the PK to dsRequest.values. This can't be done for allowMultiUpdate, since the criteria could involve operators other than just equals, there is no way to automatically translate such criteria into values.

          Note, there will often be no way to translate such criteria into values by hand, either. This just means that validators that rely on existing stored values, like the ones we have been discussing in this thread, are usually not going to work with multi-updates.

          Comment


            #80
            thanks a lot for the further clarification

            Comment

            Working...
            X