Bug Report Q241649
Visible to All Users

Validation - Rules for aggregated child objects are checked when saving a master object in a Detail View

created 15 years ago

Hi,
i have an MasterObject with an aggregated Collection. If i save the Master - why in the world are all the Objects in the Collection also validated even if they where not modified!?
Steps to Reproduce:

  1. Run the MainDemo and create a new Resume with one PortfolioFileData object (refer to the attached screenshot).
  2. Save the Resume object;
  3. Set breakpoints into the OnSaving method of both Resume and PortfolioFileData classes;
  4. Assign a Contact to the Resume object and press the Save button - see that the OnSaving method is fired only in the Resume class - this is the expected and default behavior of XPO;
  5. Now go to the database, fine the FileData table and clear the Size, FileName, Content properties columns of a row that corresponds to the PortfolioFileData object you added;
  6. Clear the Contact property of the Resume object and now press the Save button - the validation error occurs as expected because the required File property of the PortfolioFileData object is not set (we cleared it for the test purpose).
    I might be wrong, but I expect that only the rules of the Resume object should be checked in this scenario. So, since the Resume class has no validation rules no validation errors should appear here.
Comments (2)
Dennis Garavsky (DevExpress) 15 years ago

    Hello Noxe,
    >>i have an MasterObject with an aggregated Collection. If i save the Master - why in the world are all the Objects in the Collection also validated even if they where not modified!?
    As you know, the validation works against a validation context (for example, saving, deleting). When you save a master object the ObjectSpace.Committing event fires and triggers, checking the validation rules.
    However, I debugged our MainDemo a little bit (the Resume and PortfolioFileData classes), to see whether the OnSaving method hits for the PortfolioFileData class when a Resume object is saved. In my tests, I see that it's not fired and so your frustration regarding the current behavior is fully understandable. We should perform additional research in this regard, to understand whether it's possible to workaround this behavior. Anyway, I'll treat this as a bug, and will convert your question to a bug report.
    We apologize for the inconvenience it caused you and your business. We will keep you informed of our progress. Please bear with us.
    Thanks,
    Dennis

    M M
    Martin Praxmarer - DevExpress MVP 15 years ago

      Hi Dennis,
      thx for your Infos - i think the problem is in the PersistenceValidationController - GetObjectsToValidate method:
      if(currentObject != null) {
      modifiedObjects.Add(currentObject);
      aggregatedObjects.AddRange(FindAggregatedObjects(currentObject));
      modifiedObjects.AddRange(aggregatedObjects);
      }

      Answers

      created 15 years ago

      Hello Noxe,
      We could fix this problem by adding two events into the PersistenceValidationController class:

      1. CustomGetAggregatedObjectsToValidate - raised when collecting objects for the validation. You can handle this event to add aggregated objects that needs to be validated. For example, if you handle this event, set the Handled parameter to True, and clear the list of aggregated objects. Then, only modified objects will be validated. By default, if you do not handle this event, all the aggregated objects will be validated together with their master object.
      2. NeedToValidateObject - raised during the filtration of objects validation list for each validated object from this list. By default, this list is filtered with the help of context selectors (DeleteContextTargetObjectSelector, SaveContextTargetObjectSelector, SaveContextTargetObjectSelectorModifiedOnly). By handling this event, you can provide a custom filter.
        So, returning to your original issue, you can handle the CustomGetAggregatedObjectsToValidate event as follows:
      C#
      protected override void OnFrameAssigned() { ... PersistenceValidationController controller = Frame.GetController<PersistenceValidationController>(); if (controller != null){ controller.CustomGetAggregatedObjectsToValidate += delegate(object sender, CustomGetAggregatedObjectsToValidateEventArgs args) { if(args.OwnerObject is SomeType) { args.AggregatedObjects.Clear(); args.Handled = true; } }; } ...

      You can refer to the source code to see more details, after you install the public fix for this bug report. Let us know in case of any difficulty.
      Thanks,
      Dennis

        Comments (2)
        MB MB
        Mario Blatarić 8 years ago

          Hi,

          So, if I would want to disable this application-wide, I simply omit type check?
          Would that be proper approach or is there a better way to accomplish this?

          Reason I need this, customers have imported data from previous application which fail many of the validation rules defined in our application.
          Because of that, they can not insert new data for records which contain failing records in their nested collection. It even disables fixing this errors because if there are more than one failing objects in a collection it is impossible to fix any data since validation always fails (on other records).
          And since there are several dozen of objects like that, I would simply prefer to disable validation for non-edited objects - and also it is not intuitive to our customers that validation errors arise for records they are not changing and it is not possible to explain aggregated collections to average Joe in accounting.

          Regards,
          Mario

          Dennis Garavsky (DevExpress) 8 years ago

            @Mario: I've created a separate ticket on your behalf (T441376: Questions about skipping validation for certain objects with aggregated collections). It has been placed in our processing queue and will be answered shortly.

            Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

            Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.