Support writing nested delta resource sets with non-delta writer. #2250

mikepizzo · 2021-11-16T01:43:23Z

Issues

*This pull request fixes #2252 *

Description

A valid response to PATCH against a single resource with a collection is a response containing a nested delta resource set.

Today that is not possible because you can only write a delta response if you declare in your top-level resource set writer that you are writing a delta payload.

There is no longer any reason to declare up-front whether a writer is writing a delta request/response versus a non-delta request/response. A user should be able to call WriteStartDeltaResourceSet and write a delta resource set at the top level or nested within a resource.

This PR enables writing a delta resource set within a non-delta resource set writer. It retains the checks to verify that a deleted resource is only supported within a delta resource set, and an added/deleted link within a top-level delta resource set. Everything else should be common between a resourceSet and deltaResourceSet, at the top level or nested within a resource.

Checklist (Uncheck if it is not completed)

Test cases added
Build and test with one-click build and test script passed

Additional work necessary

In 8.0, remove the writingDelta flag from creating resource set writer

Sreejithpin · 2021-11-23T07:00:46Z

src/Microsoft.OData.Core/ODataWriterCore.cs

@@ -3264,8 +3269,6 @@ await thisParam.StartResourceSetAsync(resourceSetParam)
        private async Task VerifyCanWriteStartDeltaResourceSetAsync(bool synchronousCall, ODataDeltaResourceSet deltaResourceSet)
        {
            ExceptionUtils.CheckArgumentNotNull(deltaResourceSet, "deltaResourceSet");
-
-            this.VerifyWritingDelta();


Curious why was this removed

#ByDesign

Previously, this checked to see whether the writer was created with isDelta=true.

Such a check was unnecessary, and was legacy from when we had different writers under the covers for delta versus non delta collections.

It should be valid to start writing a delta resource set regardless of how the writer was created. In fact, calling writeStartDeltaResourceSet is what sets the writingDelta to true. The only thing writingDelta should validate is whether we are currently in the context of writing a delta collection (in which case we can write a deletedResource or added/deleted link) or we are not (in which case we can't).

This is particularly important for enabling writing a nested delta set within a single resource (for example, for a patch request/response) since there is no way to specify writingDelta when creating a reader/writer for a single resource.

xuzhg · 2021-11-23T22:52:18Z

src/Microsoft.OData.Core/JsonLight/ODataJsonLightWriter.cs

@@ -811,7 +810,7 @@ protected override void StartDeletedResource(ODataDeletedResource resource)
            {
                // Writing a deleted resource within an entity set
                DeltaResourceSetScope deltaResourceSetScope = this.ParentScope as DeltaResourceSetScope;
-                Debug.Assert(deltaResourceSetScope != null, "Writing child of delta set and parent scope is not DeltaResourceSetScope");
+                Debug.Assert(this.ParentScope.State == WriterState.Start || deltaResourceSetScope != null, "Writing child of delta set and parent scope is not DeltaResourceSetScope");


shall we also update the error sentence to refresh the changes?

I think the error text is still valid (and even more correct than previously). Previously the assert only checked that the parent scope was a delta resource set scope, not that what was being written was being written as the child of a delta set. The new assert validates that either the parent is scope is a deltaResourceSetScope or we're not attempting to write a child of a delta set (i.e., if the current state is start then we're writing at the top level, not as a child of a delta set.)

xuzhg · 2021-11-23T22:56:44Z

src/Microsoft.OData.Core/ODataWriterCore.cs

@@ -33,7 +33,7 @@ internal abstract class ODataWriterCore : ODataWriter, IODataOutputInStreamError
        private readonly bool writingResourceSet;

        /// <summary>True if the writer was created for writing a delta response; false otherwise.</summary>
-        private readonly bool writingDelta;
+        private readonly Stack<bool> writingDelta = new Stack<bool>();


Why cannot we put the status into the Scope?

We probably could, I was just minimizing the change for this PR, with the knowledge that this is a good candidate for clean-up in 8.0.

xuzhg · 2021-11-23T22:57:49Z

test/FunctionalTests/Microsoft.OData.Core.Tests/JsonLight/ODataJsonLightDeltaWriterTests.cs

+            }
+
+            var writer = messageWriter.CreateODataResourceWriter(this.GetCustomers(), this.GetCustomerType());
+//            ODataJsonLightWriter writer = new ODataJsonLightWriter(GetV401OutputContext(isResponse), this.GetCustomers(), this.GetCustomerType(), false, false, true);


remove unused?

or why don't use this line code?

pull-request-quantifier-deprecated · 2021-11-24T22:34:29Z

This PR has 441 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Quantification details

Label      : Extra Large
Size       : +263 -178
Percentile : 81.37%

Total files changed: 7

Change summary by file extension:
.cs : +262 -177
.txt : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detetcted.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

pull-request-quantifier-deprecated bot added the Large label Nov 16, 2021

mikepizzo force-pushed the WriteNestedDelta branch from e431407 to 60e843a Compare November 16, 2021 02:47

Support writing nested delta resource sets with non-delta writer.

00e996f

mikepizzo force-pushed the WriteNestedDelta branch from 60e843a to 00e996f Compare November 16, 2021 06:24

Support writing top-level deleted resource

ecc5b87

pull-request-quantifier-deprecated bot added Extra Large and removed Large labels Nov 16, 2021

mikepizzo marked this pull request as ready for review November 17, 2021 21:58

mikepizzo added the Ready for review Use this label if a pull request is ready to be reviewed label Nov 17, 2021

mikepizzo requested review from xuzhg, Sreejithpin, gathogojr and KenitoInc November 18, 2021 19:52

Sreejithpin reviewed Nov 23, 2021

View reviewed changes

xuzhg approved these changes Nov 23, 2021

View reviewed changes

xuzhg reviewed Nov 23, 2021

View reviewed changes

Sreejithpin approved these changes Nov 23, 2021

View reviewed changes

mikepizzo force-pushed the WriteNestedDelta branch from 4e73223 to 1e2446d Compare November 24, 2021 20:31

Track enableDelta in scope rather than introduce separate stack.

0eb4b9a

mikepizzo force-pushed the WriteNestedDelta branch from 1e2446d to 0eb4b9a Compare November 24, 2021 22:34

mikepizzo requested review from xuzhg and Sreejithpin November 24, 2021 22:34

xuzhg approved these changes Nov 24, 2021

View reviewed changes

mikepizzo merged commit 5f9cd57 into master Nov 25, 2021

mikepizzo deleted the WriteNestedDelta branch January 6, 2022 18:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support writing nested delta resource sets with non-delta writer. #2250

Support writing nested delta resource sets with non-delta writer. #2250

mikepizzo commented Nov 16, 2021 •

edited

Sreejithpin Nov 23, 2021 •

edited by mikepizzo

mikepizzo Nov 23, 2021

xuzhg Nov 23, 2021

mikepizzo Nov 23, 2021

xuzhg Nov 23, 2021

mikepizzo Nov 24, 2021

xuzhg Nov 23, 2021

xuzhg Nov 23, 2021

pull-request-quantifier-deprecated bot commented Nov 24, 2021

What can I do to optimize my changes

How to interpret the change counts in git diff output

Support writing nested delta resource sets with non-delta writer. #2250

Support writing nested delta resource sets with non-delta writer. #2250

Conversation

mikepizzo commented Nov 16, 2021 • edited

Issues

Description

Checklist (Uncheck if it is not completed)

Additional work necessary

Sreejithpin Nov 23, 2021 • edited by mikepizzo

Choose a reason for hiding this comment

mikepizzo Nov 23, 2021

Choose a reason for hiding this comment

xuzhg Nov 23, 2021

Choose a reason for hiding this comment

mikepizzo Nov 23, 2021

Choose a reason for hiding this comment

xuzhg Nov 23, 2021

Choose a reason for hiding this comment

mikepizzo Nov 24, 2021

Choose a reason for hiding this comment

xuzhg Nov 23, 2021

Choose a reason for hiding this comment

xuzhg Nov 23, 2021

Choose a reason for hiding this comment

pull-request-quantifier-deprecated bot commented Nov 24, 2021

What can I do to optimize my changes

How to interpret the change counts in git diff output

mikepizzo commented Nov 16, 2021 •

edited

Sreejithpin Nov 23, 2021 •

edited by mikepizzo