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

Retrieve only required fields from the underlying store #6650

Open
3 of 4 tasks
adriansmares opened this issue Oct 23, 2023 · 0 comments
Open
3 of 4 tasks

Retrieve only required fields from the underlying store #6650

adriansmares opened this issue Oct 23, 2023 · 0 comments
Assignees
Labels
c/network server This is related to the Network Server performance Something is slow or takes too much CPU/Memory/...

Comments

@adriansmares
Copy link
Contributor

Summary

References #6642
References TheThingsIndustries/protoc-gen-fieldmask#43

Currently the Network Server will retrieve all of the top level fields of an end device from the underlying end device store, instead of only the fields requested by the validation logic. This happens primarily in the Set RPC implementation.

Current Situation

The Set RPC implementation will retrieve all of the top level fields of the EndDevice message, instead of only the fields required by the validation.

The reason for this is that the current implementation of the Set registry method uses the SetFields method in order to filter the returned fields. The SetFields class of methods does not allow multiple oneof sub fields to be present in the requested fields - it is an error to request more than one type of oneof subfields in a single SetFields call.

SetFields imposes this limitation because it cannot discern between get and set operations. While semantically it makes sense to ask for two different oneof fields while getting an object (with the meaning of 'return the non empty one'), it is indicative of an error if multiple subfields are provided while setting an object.

Why do we need this? Who uses it, and when?

This functionality would be a performance improvement when the store implementation would change.

Proposed Implementation

If the underlying store implementation will no longer show the oneof limitation, and would benefit from only retrieving the requested fields from the store, it would be beneficial to request only the requested fields from the store.

If the store implementation would still show this oneof limitation, the protoc-gen-fieldmask plugin could provide a method which returns the common ancestor given a set of disjoint oneof fields, in order to minimize the returned fields.

Contributing

  • I can help by doing more research.
  • I can help by implementing the feature after the proposal above is approved.
  • I can help by testing the feature before it's released.

Code of Conduct

@adriansmares adriansmares added c/network server This is related to the Network Server performance Something is slow or takes too much CPU/Memory/... needs/triage We still need to triage this labels Oct 23, 2023
@adriansmares adriansmares self-assigned this Oct 23, 2023
@adriansmares adriansmares removed the needs/triage We still need to triage this label Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c/network server This is related to the Network Server performance Something is slow or takes too much CPU/Memory/...
Projects
None yet
Development

No branches or pull requests

1 participant