Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"inline" navigational properties in the delta sync response #390

Closed
congysu opened this issue Nov 20, 2015 · 4 comments
Closed

"inline" navigational properties in the delta sync response #390

congysu opened this issue Nov 20, 2015 · 4 comments
Assignees
Milestone

Comments

@congysu
Copy link
Contributor

congysu commented Nov 20, 2015

Add the ability to contain "inline" navigational properties in the delta sync response, as part of $entity.
The ask is for: protocol, ODataLib, and Client.

@lewischeng-ms
Copy link
Contributor

SWAG for this task: 2 months

  • Protocol: 1-2 weeks. Now the feature ask does not conform to OData spec: Entities include annotations for selected navigation links based on odata.metadata but MUST NOT include expanded navigation properties inline. So our team first need to go through with mikep about the validity of this feature and how future spec would support it.
  • Design: 2 weeks. To support reading and writing "inline" navigation properties in the $entity part of the delta response, both ODataJsonLightDeltaReader and ODataJsonLightDeltaWriter need to be redesigned with new scopes, say InlineDeltaFeedScope and InlineDeltaEntryScope for reading or writing inline entries, and corresponding new states. The reader and writer state machine also need to be revised accordingly. We also need to define the types used to represent the inline feed and entry. Possible options are: 1) reuse ODataFeed and ODataEntry; 2) define new types. The last part is about URL. What kind of URL should be used to request inline navigation properties? What context URL should be within the inline feed?
  • Code&Test: 2-3 weeks based on the design. What we should do includes: 1) clearly define the new state machine of the reader and the writer; 2) ensure there is no regression for existing delta cases; 3) revise URL parser and context URL builder if necessary; 4) unit and functional tests (also cover round-trip of inline entries).
  • E2E&Doc: 2 weeks. We already have a service supporting delta feature. We need to update the service with inline navigation properties and add client-side test cases. The difficult part is how to compute and present the delta changes of the inline entities. They have to keep consistent with the top-level delta feed. Also there should be a doc telling service developers how to use this new feature.

@lewischeng-ms
Copy link
Contributor

Writer: 86e4f73
Reader: f504669
E2E: #447

@lewischeng-ms
Copy link
Contributor

@lewischeng-ms
Copy link
Contributor

Current limitations on reading expanded navigation properties in delta response:

  • Cannot read the next link on an expanded feed (which means no paging support)
  • Cannot read the annotations on an expanded navigation property except its navigation link and association link
  • Cannot read the metadata reference properties of an expanded entry (usually appear in full metadata)

The only way to solve all of these problems is to "fabricate" the context URL for an expanded feed/entry in delta response so that the deserializer can have a "fake" ContextUriParseResult to parse the above links and annotations.

But there are no such limitations for the delta writer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants