NealSun96 edited a comment on issue #727: Add MetadataStoreRoutingDataWriter with DistributedLeaderElection URL: https://github.com/apache/helix/pull/727#issuecomment-584335976 > > A generic comment on all writer logics: some deletion operations can lead to a data state that is deemed "invalid" by `ZkRoutingDataReader`. For example, removing the last realmAddress, or removing the last sharding key for a realmAddress. > > Questions: > > > > 1. Do we allow that to happen? > > 2. If we don't allow that to happen, should the logic for checking these situations be a part of this PR, or a part of the validation logic PR? > > Could you include some specific examples? We could do either, but since other changes might be dependent on this diff, we could create an issue with your specific TODOs so that we could include that change in other PRs. @NealSun96 Examples: 1. "realmAddress1" is the only realm address for namespace "x", and the user wants to call `deleteMetadataStoreRealm("realmAddress1")`. 2. "/a/b/c" is the only sharding key for "realmAddressX", and the user wants to call `deleteShardingKey("realmAddressX", "/a/b/c")` which will leave the list field with 0 sharding key. We still need to think about the question 1 I posted in my first comment: do we allow this to happen? From the operations alone, they don't seem "illegal" - users should be allowed to delete things regardless if they are the last elements. But if they are allowed to do that, `ZkRoutingDataReader` will throw exceptions as it's attempting to read because it will complain "There are no metadata store realms defined" for case 1 and "Realm address does not have a value" for case 2. In my opinion, users should be allowed to delete regardless. When the last element is removed, the deletion should propagate up.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: reviews-unsubscr...@helix.apache.org For additional commands, e-mail: reviews-h...@helix.apache.org
