Context url for expand #1286

biaol-odata · 2018-10-09T19:28:28Z

Issues

This pull request fixes issue ##1265 ($expand in context url), including the two prerequisite issues #1259 and #1268. It also includes fix for issue #1104.
Please note that the PR #1264 associated with issue #1259 has been superseded by this PR, which contains the changes needed. PR #1264 will be cancelled in favor of this PR.

Description

Changes include the followings:
1). Add parenthesized token for navigation property for $expand clause in context url;
2). Context url select list parsing implementation update from ABNF V3 to ABNF V4.01 (#1268);
3). Ensure explicit selected navigation properties are present in context url (#1104);
4). Ensure navigation links are materialized for case of minimal metadata with expand-sub-select clause (#1259) .

Checklist (Uncheck if it is not completed)

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

Additional work necessary

If documentation update is needed, please add "Docs Needed" label to the issue and provide details about the required document change in the issue.

mikepizzo · 2018-10-09T22:01:39Z

src/Microsoft.OData.Core/ODataContextUrlInfo.cs

-            return string.IsNullOrEmpty(subExpand) && version <= ODataVersion.V4 ? null :
-                expandNode + ODataConstants.ContextUriProjectionStart + subExpand + ODataConstants.ContextUriProjectionEnd;
+
+            // TODO: cleanup the version parameter.


// TODO: cleanup the version parameter. [](start = 12, length = 39)

// TODO: cleanup the version parameter. [](start = 12, length = 39)

what work is left? not passing the version parameter to the method? do you have an issue filed for that? #Closed

Yes, it is just potential cleanups from caller side, wherever applicable, after reviewing changes in this PR and confirming that the dependency on version (V4/V401) should be removed. The cleanup should be straight forward when this PR is finalized. #Closed

mikepizzo · 2018-10-10T15:51:50Z

src/Microsoft.OData.Core/SelectedPropertiesNode.cs

+            {
+                // Qualified name: try to match bound and unbound operations
+                found = this.edmModel.FindBoundOperations(token, this.structuredType).Count() != 0
+                    || this.edmModel.FindDeclaredOperations(token).Count() != 0;


|| this.edmModel.FindDeclaredOperations(token).Count() != 0 [](start = 20, length = 59)

Do you have a test case for this? I don't think there should ever be unbound operations nested within parens. #Closed

Yes. In SelectedPropertiesNodeTest, we have tests exercising unbound operations using qualified name such as TestModel.Action(Edm.Int32).

In reply to: 224137533 [](ancestors = 224137533)

not sure that test is valid; the only time an operation should exist within a select list would be if it was bound to the structured type against which the select list is applied. Otherwise, the fact that there is an unbound operation with the same name is purely coincidental, and we should only resolve it as an operation if it can't be a navigation property (i.e., there is a dot in the name). So, in this case, I think the only valid interpretation would be a dynamic bound property that happened to have the same name as a defined, unbound property.

In reply to: 224629515 [](ancestors = 224629515,224137533)

The IsBoundOperationToken method has been replaced by the IsNavigationPropertyToken.

In reply to: 226138497 [](ancestors = 226138497,224629515,224137533)

mikepizzo · 2018-10-10T15:52:15Z

src/Microsoft.OData.Core/SelectedPropertiesNode.cs

+                found = this.edmModel.FindBoundOperations(token, this.structuredType).Count() != 0
+                    || this.edmModel.FindDeclaredOperations(token).Count() != 0;
+
+            }


remove extra line #Closed

mikepizzo · 2018-10-10T15:55:54Z

src/Microsoft.OData.Core/SelectedPropertiesNode.cs

+            int idx = token.LastIndexOf(nameSpaceSeparator);
+            if (idx == -1)
+            {
+                // Token is in unqualified form, try matching the unqualified name of the bound operation.


Token is in unqualified form, try matching the unqualified name of the bound operation. [](start = 19, length = 87)

Should probably add comment that, according to spec, the name should always be qualified, but that older versions of the library returned unqualified. And, we should fix the library such that it no longer returns unqualified names in the contextUrl. #Closed

Added.

In reply to: 224139113 [](ancestors = 224139113)

mikepizzo · 2018-10-10T16:04:24Z

src/Microsoft.OData.Core/UriParser/SemanticAst/SelectExpandClauseExtensions.cs

@@ -106,12 +106,10 @@ internal static void Traverse<T>(this SelectExpandClause selectExpandClause, Fun
            {
                string currentExpandClause = String.Join("/", expandSelectItem.PathToNavigationProperty.WalkWith(PathSegmentToStringTranslator.Instance).ToArray());
                T subResult = default(T);


= default(T) [](start = 27, length = 13)

Since you are no longer conditionally calling Traverse, do you still need to initialize subResult? #Closed

mikepizzo · 2018-10-10T16:12:17Z

src/Microsoft.OData.Core/UriParser/SemanticAst/SelectExpandClauseExtensions.cs

@@ -106,12 +106,10 @@ internal static void Traverse<T>(this SelectExpandClause selectExpandClause, Fun
            {
                string currentExpandClause = String.Join("/", expandSelectItem.PathToNavigationProperty.WalkWith(PathSegmentToStringTranslator.Instance).ToArray());
                T subResult = default(T);
-                if (expandSelectItem.SelectAndExpand.SelectedItems.Any())


expandSelectItem.SelectAndExpand.SelectedItems.Any()) [](start = 20, length = 53)

expandSelectItem.SelectAndExpand.SelectedItems.Any()) [](start = 20, length = 53)

why are you removing this check? won't traverse always return an empty subresult if there are no items in SelectedItems? #Closed

restored. Same outcome.

In reply to: 224144946 [](ancestors = 224144946)

mikepizzo · 2018-10-10T16:16:28Z

test/EndToEndTests/Tests/Client/Build.Desktop/ContainmentTest/ContainmentTest.cs

-                { "Accounts(101)?$expand=MyPaymentInstruments", new int[] {4, 15} },
-                { "Accounts(101)?$select=AccountID&$expand=MyGiftCard($select=GiftCardID)", new int[] {2, 1}  }
+                { "Accounts(101)?$select=AccountInfo/FirstName, AccountInfo/LastName", new int[] {1, 0, 0} },
+                { "Accounts(101)?$select=AccountID&$expand=MyPaymentInstruments($select=PaymentInstrumentID;$expand=TheStoredPI)", new int[]{7,4,4} },


{ "Accounts(101)?$select=AccountID&$expand=MyPaymentInstruments($select=PaymentInstrumentID;$expand=TheStoredPI) [](start = 0, length = 128)

{ "Accounts(101)?$select=AccountID&$expand=MyPaymentInstruments($select=PaymentInstrumentID;$expand=TheStoredPI) [](start = 0, length = 128)

Do we have any test cases that test multiple nested levels of expand? i.e., $select=AccountID&$expand=MyPaymentInstruments($select=PaymentInstrumentID;$expand=TheStoredPI($select=someproponstoredpi))? #Closed

mikepizzo · 2018-10-10T16:22:02Z

test/EndToEndTests/Tests/Client/Build.Desktop/ContainmentTest/ContainmentTest.cs

+                            int expectedLinksCount = mimeType.Contains(MimeTypes.ODataParameterFullMetadata)
+                                ? testCase.Value[1]
+                                : testCase.Value[2];
+                            Assert.AreEqual(expectedLinksCount, navigationLinks.Count);


Let's discuss. I wouldn't expect expectedLinksCount to vary depending on the full versus minimal metadata. #Closed

For the case of "Accounts(101)?$expand=MyPaymentInstruments($select=PaymentInstrumentID,FriendlyName)", full metadata response contains nav links for entities contained by PaymentInstruments, which are not supposed to be materialized in the minimal metadata response.

Edit:
I have made an update to SelectedPropertiesNode.Create(SelectExpandClause) to return entire tree only when AllSelected are true for current level and expanded entities.
Thanks for the catch! #Closed

👍

In reply to: 224632181 [](ancestors = 224632181)

mikepizzo · 2018-10-10T16:29:37Z

test/FunctionalTests/Microsoft.OData.Core.Tests/ODataContextUriBuilderTests.cs

@@ -211,13 +211,13 @@ public void EntryContextUriWithSelectString()

        [Theory]
        // expand without select, $expand=A
-        [InlineData(ODataVersion.V4, "TestModel.CapitolCity/Districts", "")]
+        [InlineData(ODataVersion.V4, "TestModel.CapitolCity/Districts", "TestModel.CapitolCity/Districts()")]
        [InlineData(ODataVersion.V401, "TestModel.CapitolCity/Districts", "TestModel.CapitolCity/Districts()")]


Since 4.0 and 4.01 are now the same, we can simplify these tests (and ensure 4.0 and 4.01 are the same) by removing the ODataVersion from the InlineData and having the tests run for both 4.0 and 4.01. #Closed

OK. cases merged.

In reply to: 224151289 [](ancestors = 224151289)

mikepizzo · 2018-10-10T17:06:21Z

test/FunctionalTests/Microsoft.OData.Core.Tests/ODataContextUriBuilderTests.cs

-        [InlineData(ODataVersion.V401, "Districts(City(Districts()))")]
-        public void EntryContextUriWithExpandNestedExpandString(ODataVersion version, string expectedExpandWithoutNesting)
+        [InlineData(ODataVersion.V4)]
+        [InlineData(ODataVersion.V401)]


can just remove inlinedata and run for v4 and v401. #Closed

mikepizzo · 2018-10-10T17:13:11Z

...ionalTests/Microsoft.OData.Core.Tests/ScenarioTests/Roundtrip/ContextUrlWriterReaderTests.cs

@@ -737,7 +737,7 @@ public void CollectionOfProjectedExpandedEntities()
        // Sample Request: http://host/service/Employees?$expand=Company
        // Context Url in Response: http://host/service/$metadata#Employees(Company())
        [Theory]
-        [InlineData(ODataVersion.V4, "\"{0}$metadata#Employees\"")]
+        [InlineData(ODataVersion.V4, "\"{0}$metadata#Employees(AssociatedCompany())\"")]
        [InlineData(ODataVersion.V401, "\"{0}$metadata#Employees(AssociatedCompany())\"")]


again, can just run test for v4 and v4.01 with same string. #Closed

mikepizzo · 2018-10-10T17:22:03Z

...sts/Microsoft.OData.Core.Tests/ScenarioTests/UriParser/ExpandAndSelectPathExtractingTests.cs

@@ -228,15 +228,15 @@ public void ExpandNavigationThatIsNotSelectedAutomaticallySelectsLink()
        {
            const string selectClauseText = "Navigation2";
            const string expandClauseText = "Navigation1";
-            const string expectedSelectClause = "Navigation2,Navigation1";
+            const string expectedSelectClause = "Navigation2";


Now that they (happily) match, you can get rid of expectedSelectClaus, and just pass in selectClause in both places. #Closed

mikepizzo · 2018-10-10T17:22:39Z

...sts/Microsoft.OData.Core.Tests/ScenarioTests/UriParser/ExpandAndSelectPathExtractingTests.cs

@@ -228,15 +228,15 @@ public void ExpandNavigationThatIsNotSelectedAutomaticallySelectsLink()
        {
            const string selectClauseText = "Navigation2";
            const string expandClauseText = "Navigation1";
-            const string expectedSelectClause = "Navigation2,Navigation1";
+            const string expectedSelectClause = "Navigation2";
            this.ParseAndExtract(selectClauseText: selectClauseText, expandClauseText: expandClauseText, expectedSelectClauseFromOM: expectedSelectClause, expectedExpandClauseFromOM: "Navigation1");


"Navigation1" [](start = 183, length = 13)

"Navigation1" [](start = 183, length = 13)

seems like this should just be "expandClauseText" #Closed

mikepizzo · 2018-10-10T17:23:43Z

...sts/Microsoft.OData.Core.Tests/ScenarioTests/UriParser/ExpandAndSelectPathExtractingTests.cs

            this.ParseAndExtract(selectClauseText: selectClauseText, expandClauseText: expandClauseText, expectedSelectClauseFromOM: expectedSelectClause, expectedExpandClauseFromOM: "Navigation1");
        }

        [Fact]
        public void ExpandNavigationThatIsNotSelectedInNonTopLevelAutomaticallySelectsLink()
        {
            const string expandClauseText = "Navigation1($select=Navigation1;$expand=Navigation2)";
-            const string expectedExpandClauseText = "Navigation1($select=Navigation1,Navigation2;$expand=Navigation2)";
+            const string expectedExpandClauseText = "Navigation1($select=Navigation1;$expand=Navigation2)";
            this.ParseAndExtract(selectClauseText: null, expandClauseText: expandClauseText, expectedSelectClauseFromOM: null, expectedExpandClauseFromOM: expectedExpandClauseText);


should be able to get rid of this and just pass in expandClauseText (further enforcing that the expected is the same as the provided.) #Closed

mikepizzo · 2018-10-10T17:27:08Z

...ionalTests/Microsoft.OData.Core.Tests/ScenarioTests/UriParser/SelectExpandFunctionalTests.cs

@@ -1021,7 +1019,7 @@ public void ExpandSyntacticErrorMessageSpecifiesExpandAsWellAsSelect()
        public void MixOfSelectionTypesShouldWork()
        {
            const string select = "Name,Birthdate,MyAddress,Fully.Qualified.Namespace.*,MyLions";
-            const string expectedSelect = "Name,Birthdate,MyAddress,Fully.Qualified.Namespace.*,MyLions,MyDog";
+            const string expectedSelect = "Name,Birthdate,MyAddress,Fully.Qualified.Namespace.*,MyLions";
            const string expand = "MyDog";


since select is (by design) same as expectedSelect, you can get rid of expectedSelect and just use select. #Closed

mikepizzo · 2018-10-10T17:28:01Z

...ionalTests/Microsoft.OData.Core.Tests/ScenarioTests/UriParser/SelectExpandFunctionalTests.cs

        {
            const string expandClauseText = "MyDog($select=Color;$expand=MyPeople)";
            const string selectClauseText = "";
-            const string expectedExpandClauseText = "MyDog($select=Color,MyPeople;$expand=MyPeople)";
+            const string expectedExpandClauseText = "MyDog($select=Color;$expand=MyPeople)";
            const string expectedSelectClause = "";


remove; just use expandClauseText #Closed

xuzhg · 2018-10-10T17:29:54Z

src/Microsoft.OData.Core/ODataContextUrlInfo.cs

@@ -403,8 +403,9 @@ private static string CreateSelectExpandContextUriSegment(SelectExpandClause sel
        /// <returns>The generated expand string.</returns>
        private static string ProcessSubExpand(string expandNode, string subExpand, ODataVersion version)
        {
-            return string.IsNullOrEmpty(subExpand) && version <= ODataVersion.V4 ? null :


string.IsNullOrEmpty(subExpand) [](start = 19, length = 31)

Should we keep "string.IsNullOrEmpty(subExpand) " check and return "null"? #Resolved

We do need to include the case of null and return "()" for expanded entity.

In reply to: 224171315 [](ancestors = 224171315)

mikepizzo · 2018-10-10T19:12:31Z

...lectExpand/SelectExpandTest.DeepSelectionsAreRedundantIfEntireSubtreeIsSelected.approved.txt

@@ -22,5 +22,4 @@ SelectExpandQueryOption
 										SelectedItems
 											Path]


Is this a bug in the test or the code? I would have expected this to write out the selected function. #Resolved

The selected function "OrdersWithMoreThanTwoItems" is bound to entity collection but not the entity type.

In reply to: 224206728 [](ancestors = 224206728)

…s only expand tokens.

…items.

biaol-odata · 2018-10-12T01:00:52Z

@mikepizzo @xuzhg Thanks for the code review! Please check the latest commit, and let me know if there any other outstanding issues. #Resolved

- cleanups - Create SelectedPropertiesnode based on AllSelected values of current level and expanded nav properties.

biaol-odata · 2018-10-16T21:00:50Z

ODL nightly Microsoft.OData.Core.7.6.0-Nightly201810151853 has been generated on the commit above and successfully validated by WebAPI project. #Resolved

mikepizzo · 2018-10-17T23:57:48Z

...ionalTests/Microsoft.OData.Core.Tests/ScenarioTests/Roundtrip/ContextUrlWriterReaderTests.cs

-        [InlineData(ODataVersion.V4, "\"{0}$metadata#Employees(AssociatedCompany)/$entity\"")]
-        [InlineData(ODataVersion.V401, "\"{0}$metadata#Employees(AssociatedCompany())/$entity\"")]
+        [InlineData(ODataVersion.V4, "\"{0}$metadata#Employees(AssociatedCompany,AssociatedCompany())/$entity\"")]
+        [InlineData(ODataVersion.V401, "\"{0}$metadata#Employees(AssociatedCompany,AssociatedCompany())/$entity\"")]
        public void ExpandedMultiSegmentEntity(ODataVersion version, string contextString)


Here again, we should just have a single string defined for the contextString and run the test for each ODataVersion using that same string definition (to enforce that the two versions don't diverge) #Closed

Consolidated the two test cases. Thanks!
I have also checked the rest of the changes, looks like there are no other cases similar to these that can be combined.

In reply to: 226131792 [](ancestors = 226131792)

mikepizzo · 2018-10-17T23:59:47Z

...sts/Microsoft.OData.Core.Tests/ScenarioTests/UriParser/ExpandAndSelectPathExtractingTests.cs

@@ -228,16 +228,14 @@ public void ExpandNavigationThatIsNotSelectedAutomaticallySelectsLink()
        {
            const string selectClauseText = "Navigation2";
            const string expandClauseText = "Navigation1";
-            const string expectedSelectClause = "Navigation2,Navigation1";
-            this.ParseAndExtract(selectClauseText: selectClauseText, expandClauseText: expandClauseText, expectedSelectClauseFromOM: expectedSelectClause, expectedExpandClauseFromOM: "Navigation1");
+            this.ParseAndExtract(selectClauseText: selectClauseText, expandClauseText: expandClauseText, expectedSelectClauseFromOM: selectClauseText, expectedExpandClauseFromOM: "Navigation1");


"Navigation1" [](start = 179, length = 13)

Should just be expandClauseText #Closed

Yup. Updated.

In reply to: 226132107 [](ancestors = 226132107)

mikepizzo · 2018-10-18T00:27:11Z

src/Microsoft.OData.Core/SelectedPropertiesNode.cs

+                found = this.edmModel.FindDeclaredBoundOperations(this.structuredType)
+                        .Any(op => op.Name.Equals(token, StringComparison.Ordinal));
+            }
+            else


if the segment matches a declared navigation property, it is evaluated as a navigation property even if there is a bound operation with the same unqualified name. That's why the qualified name needs to be used to disambiguate a bound function from a defined navigation property. Our logic needs to conceptually be:

if it doesn't have parens, it's not a navigation property. Otherwise, if it has parens, then:

if it matches a defined navigation property => treat it as a navigation property

otherwise, if the name contains a dot => it's not a navigation property

otherwise, if it matches an unqualified bound operation name => it's not a navigation property

otherwise, it's a navigation property

Note that 3) is only required if we believe there are existing (invalid) responses containing unqualified bound operation names. If we don't believe that's the case, the logic becomes much simpler: if the name has parens and does not have a dot in the name, it's a nav prop. #Closed

Updated. Using the new method IsNavigationPropertyToken for the original !IsBoundOperation(). In the new method, implements the logic above, applying the rationale about qualified name for operation.

In reply to: 226136554 [](ancestors = 226136554)

mikepizzo · 2018-10-18T00:29:16Z

src/Microsoft.OData.Core/SelectedPropertiesNode.cs

+            {
+                // Qualified name: try to match bound and unbound operations
+                found = this.edmModel.FindBoundOperations(token, this.structuredType).Count() != 0
+                    || this.edmModel.FindDeclaredOperations(token).Count() != 0;


|| this.edmModel.FindDeclaredOperations(token).Count() != 0 [](start = 20, length = 59)

See above; if it contains a dot we should already have omitted it. Otherwise, if the select list contains the unqualified name of an operation not bound to the current type, it should not be treated as an operation. #Resolved

mikepizzo · 2018-10-18T00:36:14Z

test/FunctionalTests/Microsoft.OData.Core.Tests/SelectedPropertiesNodeTests.cs

        {
-            SelectedPropertiesNode.Create("Action(Edm.Int32)").Should().HaveAction(this.cityType, this.action);
+            SelectedPropertiesNode.Create("Action(Edm.Int32)", this.cityType, this.edmModel).Should().NotHaveAction(this.cityType, this.action);
        }


the old version of this method created the selected properties node as the top-level node, which is valid for an unbound operation. With this change, you are selecting an unbound action from a type, which is not valid.

removed this invalid case.

In reply to: 226137870 [](ancestors = 226137870)

Actually, the original case was valid, because it could be creating selectedpropertiesnode for a top level action/action import. It was only your proposed change that nested bound it to this.cityType, that was invalid.

In reply to: 226493137 [](ancestors = 226493137,226137870)

biaol-odata · 2018-10-18T23:27:27Z

@mikepizzo PR has been updated per your comments. Can you please take a look to whether there are anything else outstanding?
#Resolved

mikepizzo · 2018-10-22T15:35:55Z

src/Microsoft.OData.Core/SelectedPropertiesNode.cs

+
+            // For better readability, set the value in if-else branches corresponding to decision tree above.
+            bool found;
+            if (this.structuredType.NavigationProperties().Any(_ => _.Name.Equals(token, StringComparison.Ordinal)))


StringComparison.Ordinal [](start = 89, length = 24)

Should respect case-sensitivity of current ODataUriResolver. #Closed

mikepizzo · 2018-10-22T17:35:20Z

src/Microsoft.OData.Core/SelectedPropertiesNode.cs

+                found = true;
+            }
+            else if (token.IndexOf(nameSpaceSeparator) != -1 ||
+                     this.edmModel.FindBoundOperations(this.structuredType).Any(op => op.Name.Equals(token, StringComparison.Ordinal)))


op.Name.Equals(token, StringComparison.Ordinal) [](start = 86, length = 47)

This should also use case sensitivity of UriResolver. #Closed

Actually, as Biao points out, this in the contextUrl which is case-normalized.

In reply to: 227065902 [](ancestors = 227065902)

mikepizzo

* Set the selectionType to EntireSubtree when the selected list contains only expand tokens. * For $expand, add navProp() to context-url. * ABNF v4; ensure explicit select; don't add link for expand to select items. * Resolve CR comments. - cleanups - Create SelectedPropertiesnode based on AllSelected values of current level and expanded nav properties. * Update for navProp token resolution logic per CR comments; cleanups

This reverts commit ec6fb33.

Revert "Context url for expand (OData#1286)" This reverts commit ec6fb33. Original PR not only modified how @odata.context formed for v4.0 and v4.01, but also removed a lot of version recognition code. That makes it’s pretty difficult to do conditionally. Please, keep in mind that default protocol version is v4.0 and client had to say that it wants v4.01. In AX I'm going to add telemetry to allow us to see what clients asked for Related work items: #1426955

biaol-odata requested review from raheph, mikepizzo, xuzhg, AlanWong-MS and KanishManuja-MS October 9, 2018 19:28

biaol-odata mentioned this pull request Oct 9, 2018

Set the selectionType to EntireSubtree when the selected list contain… #1264

Closed

2 tasks

biaol-odata force-pushed the ContextUrlForExpand branch 2 times, most recently from 2549c22 to 27c8593 Compare October 9, 2018 21:54

mikepizzo reviewed Oct 9, 2018

View reviewed changes

mikepizzo reviewed Oct 10, 2018

View reviewed changes

xuzhg reviewed Oct 10, 2018

View reviewed changes

mikepizzo reviewed Oct 10, 2018

View reviewed changes

biaol-odata added 3 commits October 11, 2018 17:35

Set the selectionType to EntireSubtree when the selected list contain…

b3c0e51

…s only expand tokens.

For $expand, add navProp() to context-url.

026b8f6

ABNF v4; ensure explicit select; don't add link for expand to select …

215f7ff

…items.

biaol-odata force-pushed the ContextUrlForExpand branch from c91c50a to a09889e Compare October 12, 2018 00:56

biaol-odata force-pushed the ContextUrlForExpand branch 2 times, most recently from f9a7377 to bc69d1d Compare October 14, 2018 21:51

Resolve CR comments.

4933eca

- cleanups - Create SelectedPropertiesnode based on AllSelected values of current level and expanded nav properties.

biaol-odata force-pushed the ContextUrlForExpand branch from bc69d1d to 4933eca Compare October 15, 2018 03:26

mikepizzo reviewed Oct 17, 2018

View reviewed changes

mikepizzo reviewed Oct 18, 2018

View reviewed changes

Update for navProp token resolution logic per CR comments; cleanups

e1e7744

mikepizzo reviewed Oct 22, 2018

View reviewed changes

mikepizzo approved these changes Oct 22, 2018

View reviewed changes

biaol-odata merged commit ec6fb33 into OData:master Oct 22, 2018

biaol-odata deleted the ContextUrlForExpand branch October 23, 2018 18:59

mikepizzo mentioned this pull request Dec 12, 2018

Fix SelectExpandNode for navigation properties on derived/complex types #1359

Merged

mikepizzo mentioned this pull request Jan 24, 2019

Revert writing empty parens for expanded nav prop in 4.0 response #1383

Closed

This was referenced Feb 12, 2019

Revert empty parentheses for expanded navigation properties without su… #1402

Closed

OData context uri for v4 - revert empty parentheses for navigation properties #1407

Closed

kosinsky added a commit to kosinsky/odata.net that referenced this pull request May 4, 2020

Revert "Context url for expand (OData#1286)"

46a9b53

This reverts commit ec6fb33.

Context url for expand #1286

Context url for expand #1286

Conversation

biaol-odata commented Oct 9, 2018

Issues

Description

Checklist (Uncheck if it is not completed)

Additional work necessary

mikepizzo Oct 9, 2018 • edited Loading

Choose a reason for hiding this comment

biaol-odata Oct 10, 2018 • edited by mikepizzo Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikepizzo Oct 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

biaol-odata Oct 11, 2018 • edited by mikepizzo Loading

Choose a reason for hiding this comment

mikepizzo Oct 18, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited Loading

Choose a reason for hiding this comment

xuzhg Oct 10, 2018 • edited by biaol-odata Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikepizzo Oct 10, 2018 • edited by biaol-odata Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

biaol-odata commented Oct 12, 2018 • edited Loading

biaol-odata commented Oct 16, 2018 • edited Loading

mikepizzo Oct 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikepizzo Oct 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikepizzo Oct 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikepizzo Oct 18, 2018 • edited by biaol-odata Loading

Choose a reason for hiding this comment

mikepizzo Oct 18, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

biaol-odata commented Oct 18, 2018 • edited Loading

mikepizzo Oct 22, 2018 • edited Loading

Choose a reason for hiding this comment

mikepizzo Oct 22, 2018 • edited Loading

mikepizzo Oct 9, 2018 •

edited

Loading

biaol-odata Oct 10, 2018 •

edited by mikepizzo

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 18, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

biaol-odata Oct 11, 2018 •

edited by mikepizzo

Loading

mikepizzo Oct 18, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

mikepizzo Oct 10, 2018 •

edited

Loading

xuzhg Oct 10, 2018 •

edited by biaol-odata

Loading

mikepizzo Oct 10, 2018 •

edited by biaol-odata

Loading

biaol-odata commented Oct 12, 2018 •

edited

Loading

biaol-odata commented Oct 16, 2018 •

edited

Loading

mikepizzo Oct 17, 2018 •

edited

Loading

mikepizzo Oct 17, 2018 •

edited

Loading

mikepizzo Oct 18, 2018 •

edited

Loading

mikepizzo Oct 18, 2018 •

edited by biaol-odata

Loading

mikepizzo Oct 18, 2018 •

edited

Loading

biaol-odata commented Oct 18, 2018 •

edited

Loading

mikepizzo Oct 22, 2018 •

edited

Loading

mikepizzo Oct 22, 2018 •

edited

Loading