Skip to content
GitLab

Adapters for PartitionInfo

Closed Komal Makkar requested to merge users/komakkar/eventgridClient into master

All Submissions:

  • [YES] I have added an explanation of what changes in this merge do and why we should include it?
  • [NO] Does the MR contain pipeline/ helm chart related changes?
  • [YES] I have updated the documentation accordingly.
  • [NA] I have added tests to cover my changes.
  • [NA] All new and existing tests passed.
  • [YES] My code follows the code style of this project.
  • [YES] I ran lint checks locally prior to submission.

What is the issue or story related to the change?

Note: The MR is not an implementation MR. Hence, please don't expect tests to be in place.

Existing Behaviour: The PartitionInfo is not consumable easily. PartitionInfoAzure was the means to consume it. The deserialization had hardcoded the keys of the map. This limits us to add keys on the fly and consume those. The right-hand side is the representation of how we are consuming it today.

Modified Behaviour: The left hand represents the modified behavior. We can break it down as follows to understand it better.

  1. Breaking free from PartitionInfoAzure. We encourage Data Models for each resource type, for instance, EventGridPartitionConfig.
  2. Adapter for creating the config. These adapters are supposed to convert PartitionInfoAzure to Config data model. For instance EventGridPartitionConfigAdapter.
  3. PartitionInfoProvider. This provider is meant to make sure the infra stores have the access to PartitionInfo. PartitionInfo is supplied to the adapters.

High level design: image

Issue: #6

Change details:

Test coverage:

Does this introduce a breaking change?

  • [YES/NO] No

Pending items

Reviewer request

  • Please provide an ETA when you plan to review this MR. Write a comment to decline or provide an ETA.
  • Block the MR if you feel there is less testing or no details in the MR
  • Please cover the following aspects in the MR -- Coding design: <Reviewer1> -- Backward Compatibility: <Reviewer2> -- Feature Logic: <Logic design> -- <Any other context mention here> OR -- <Component 1>: <Reviewer1> -- <CosmosDB>: <Reviewer2> -- <ServiceBus> <Reviewer3> -- <Mention any other component and owner>

Other information

Edited by Komal Makkar