It's like double-entry bookkeeping, but for descriptors!
Presently, we have the GetReferencedDescIDs on catalog.Descriptor which returns the a set of descriptor IDs which includes all forward-referenced and back-referenced descriptor IDs. Well, that is, barring any bugs such as #77140.
The descriptor validation logic uses this method when validating a descriptor during its cross-reference checking (these are the checks that run at the catalog.ValidationLevelCrossReferences level). It uses it to load all descriptors to make them accessible via a ValidationDescGetter.
We want an extra generic validation check at the catalog.ValidationLevelCrossReferences level which checks that:
for each validated descriptor,
for each ID returned by GetReferencedDescIDs for the validated descriptor,
the ID set returned by calling GetReferencedDescIDs on the descriptor in step (2) includes the ID of the descriptor in step (1).
This way, we can validate that each forward reference also has a back-reference, and vice-versa.
It's like double-entry bookkeeping, but for descriptors!
Presently, we have the
GetReferencedDescIDs
oncatalog.Descriptor
which returns the a set of descriptor IDs which includes all forward-referenced and back-referenced descriptor IDs. Well, that is, barring any bugs such as #77140.The descriptor validation logic uses this method when validating a descriptor during its cross-reference checking (these are the checks that run at the
catalog.ValidationLevelCrossReferences
level). It uses it to load all descriptors to make them accessible via aValidationDescGetter
.We want an extra generic validation check at the
catalog.ValidationLevelCrossReferences
level which checks that:This way, we can validate that each forward reference also has a back-reference, and vice-versa.
Jira issue: CRDB-13430