#907: Enable read the untyped collection #905

xuzhg · 2023-05-02T20:27:55Z

fixes #907.

also part of fixes #885. (No breaking changes)

Enable read the untyped collection.

For example:

{
 "awsTag":[
            null,
            {
                "X1": "Red",
                "Data": {
                    "D1": 42
                }
            },
            "finance",
            "hr",
            "legal",
            43
        ]
}

where, awsTag could be a dynamic property, it contains primitive value item, resource value item.

ODL reads it and returns:

ODataReaderState.Primitive for primitive value in collection
ODataReaderState.ResourceStart for resource value in collection.
It also can contain collection value item again in the collection.

This PR is to handle the above scenario.

corranrogue9 · 2023-05-02T20:54:00Z

src/Microsoft.AspNetCore.OData/Formatter/Wrapper/ODataResourceSetWrapper.cs

+        /// This list is used to hold other items, for example a primitive or a collection, etc.
+        /// In the next major release, we should combine 'Resources' and 'Items' together.
+        /// </summary>
+        public IList<ODataItemWrapper> Items { get; }


Is there supposed to be code somewhere that reads the Items property to actually populate the CLR type?

What do you mean? @corranrogue9

To add a Kind property in the base type and implement to return different kind in different wrapper?

I also have a similar question:

Why do we need to make it public? Do we expect customers to use this?

If we make it public, do we expect customers be both read and update the collection?

Since 'Resources' is open/public, we can't stop customers adding new resources into that.
Same reason, we can't stop customers to modify the 'Items'.

Items is being introduced in this PR, so it doesn't exist in existing code. So my question was whether we need to expose it to customers and why.

Customer may override the 'CreateResourceSet' method in ODataResourceSetDeserializer to access the 'Items'.

src/Microsoft.AspNetCore.OData/Formatter/Wrapper/ODataReaderExtensions.cs

habbes · 2023-05-03T17:07:34Z

src/Microsoft.AspNetCore.OData/Formatter/Wrapper/ODataReaderExtensions.cs

@@ -301,11 +310,18 @@ private static void ReadResourceSet(ODataReader reader, Stack<ODataItemWrapper>
            ODataResourceSetWrapper resourceSetWrapper = new ODataResourceSetWrapper(resourceSet);
            if (itemsStack.Count > 0)
            {
-                ODataNestedResourceInfoWrapper parentNestedResourceInfo = (ODataNestedResourceInfoWrapper)itemsStack.Peek();
-                Contract.Assert(parentNestedResourceInfo != null, "this has to be an inner resource set. inner resource sets always have a nested resource info.");


Can itemStack contain null entries? Or does this assertion (and others like it in this class) make the assumption that the cast will return null if the conversion fails? If the item at the top of the stack is not the expected type, an InvalidCastException will be thrown. If we expect null, we should consider using itemStack.Peek() as ODataNestedResourceInfoWrapper.
But I don't mind throwing the exception if that was by design.

I know this doesn't apply to the new code change, but I've seen it in other places in this class and thought it's worth pointing out.

ODL reading logic guarantees so far.
In my plan, I will retrieve the reading as a service and customer can customize the reading process. It's a future feature.

The guarantee makes sense. My comment was more on the fact that Contact.Assert verifies that the parentNestedResourceInfo is not null. However, if the cast would have failed, parentNestedResourceInfo would not have been set to null, an exception would have been thrown, and therefore the Contact.Assert would not have been reached.

itemsStack.Peek() could return 'null', I think.
ODataNestedResourceInfoWrapper parentNestedResourceInfo = (ODataNestedResourceInfoWrapper)null;

is valid. We can sync it more, but it's no scope of this PR. :)

src/Microsoft.AspNetCore.OData/Formatter/Wrapper/ODataReaderExtensions.cs

habbes · 2023-05-03T17:37:38Z

src/Microsoft.AspNetCore.OData/Formatter/Wrapper/ODataResourceSetWrapper.cs

+        /// <summary>
+        /// Gets the nested items of this ResourceSet.
+        /// Since we have 'Resources' to contain ODataResource items in the collection (we have to keep it avoid breaking changes).
+        /// This list is used to hold other items, for example a primitive or a collection, etc.


By this you mean that Items and Resources have no overlap? Or does Items also include Resources?

It depends on the question:
Does the items order in a collection matter?

If it does matter, I will make Items to include all in 'Resources'.

If it doesn't matter, I will sperate them.

So, the idea is to replace

-public ILIist<ODataResourceWrapper> Resources {get;} +public ILIist<ODataItemWrapper> Resources {get;}

What about the current implementation? Does the order matter? Does Items in the current implementation of this PR include resources?

The PR doesn't include 'Resources' items into "Items".
In my opinion, the order doesn't matter. But we can change it anytime if the order does matter.

habbes · 2023-05-03T17:39:15Z

src/Microsoft.AspNetCore.OData/Formatter/Wrapper/ODataResourceSetWrapper.cs

+        /// This list is used to hold other items, for example a primitive or a collection, etc.
+        /// In the next major release, we should combine 'Resources' and 'Items' together.
+        /// </summary>
+        public IList<ODataItemWrapper> Items { get; }


I also have a similar question:

Why do we need to make it public? Do we expect customers to use this?

If we make it public, do we expect customers be both read and update the collection?

test/Microsoft.AspNetCore.OData.Tests/Formatter/Wrapper/ODataReaderExtensionsTests.Untyped.cs

…tensions.cs Co-authored-by: Clément Habinshuti <clhabins@microsoft.com>

… 'Items' also to keep it same order

Part of Issue #885: Enable read the untyped collection

271380f

xuzhg requested review from habbes, corranrogue9, gathogojr, lisicase and mikepizzo May 2, 2023 20:28

corranrogue9 reviewed May 2, 2023

View reviewed changes

xuzhg changed the title ~~Part of Issue #885: Enable read the untyped collection~~ #907: Enable read the untyped collection May 3, 2023

habbes reviewed May 3, 2023

View reviewed changes

xuzhg and others added 3 commits May 3, 2023 10:57

Update src/Microsoft.AspNetCore.OData/Formatter/Wrapper/ODataReaderEx…

22a72c4

…tensions.cs Co-authored-by: Clément Habinshuti <clhabins@microsoft.com>

rename the variable name

9c91d77

We consider the order does matter, let's save items in 'Resources' to…

c07a245

… 'Items' also to keep it same order

habbes approved these changes May 3, 2023

View reviewed changes

xuzhg merged commit f80c8ec into main May 3, 2023
2 checks passed

xuzhg mentioned this pull request May 4, 2023

Allow reading primitive, collection in a collection #909

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

#907: Enable read the untyped collection #905

#907: Enable read the untyped collection #905

xuzhg commented May 2, 2023 •

edited

Loading

corranrogue9 May 2, 2023

xuzhg May 3, 2023

habbes May 3, 2023

xuzhg May 3, 2023

habbes May 3, 2023

xuzhg May 3, 2023

habbes May 3, 2023

habbes May 3, 2023

habbes May 3, 2023

xuzhg May 3, 2023

habbes May 3, 2023

xuzhg May 3, 2023

habbes May 3, 2023

xuzhg May 3, 2023

habbes May 3, 2023

xuzhg May 3, 2023

habbes May 3, 2023

#907: Enable read the untyped collection #905

#907: Enable read the untyped collection #905

Conversation

xuzhg commented May 2, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xuzhg commented May 2, 2023 •

edited

Loading