feat: Add explicit is_deleted endpoint to the registry canister. #9327
feat: Add explicit is_deleted endpoint to the registry canister. #9327michael-weigelt wants to merge 2 commits intomasterfrom
is_deleted endpoint to the registry canister. #9327Conversation
| .rev() | ||
| .find(|value| value.version <= version)?; | ||
| match &result.content { | ||
| Some(high_capacity_registry_value::Content::DeletionMarker(_)) => Some(true), |
There was a problem hiding this comment.
-
Why is there a bool inside
Content::DeletionMarker(bool)? The type and its usage (as far as I could see) imply thatContent::DeletionMarkerwould have been enough, andContent::DeletionMarker(false)is an illegal/nonsensical data combination. -
Why is
HighCapacityRegistryValue.contentan Option if theContentenum already accounts for absent data viaDeletionMarker. Could thecontentbe absent in any other way? In other words, what in what scenario iscontent == None?
(If the answer has to do with protobuf, then bonus question: Why not define pb types that are separate from the types used in regular Rust code and make only legal states representable there?)
is_deleted endpoint to registry canister. is_deleted endpoint to the registry canister.
| Some(result) | ||
| } | ||
|
|
||
| /// Returns `Some(true)` if the value for the given `key` is deleted at `version`. |
There was a problem hiding this comment.
We could also make this into an enum with names that speak for themselves. But there is a single internal consumer, so it is probably not that important.
The
getmethod of the registry canister returnsNoneif the key does not exist at the given version, or if it was deleted. This makes it difficult to distinguish whether a value has been deleted or was never present.Sometimes, callers want to act on positive data, rather than on the absence of data.
is_deletedis an unambiguous signal that a value once existed but was explicitly deleted, allowing such callers to proceed with confidence.This PR simply exposes this internally existing information to callers.