Restrict adding primary key of one subject as additional key of another subject #118
Labels
No labels
P0
P1
P2
P3
good first issue
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Blocks
#1436 Support secondary keys in FrostFSID contract}
TrueCloudLab/frostfs-node
Reference: TrueCloudLab/frostfs-contract#118
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Subj.
This test pass and it doesn't seem right to me. To use additional keys in TrueCloudLab/frostfs-node#1436 and TrueCloudLab/frostfs-s3-gw#518 it would be much more convenient to check if key is already used as primary key.
Similar question: do we want to have same secondary key belonging to different subjects?
Does it make sense?
I suggest to modify contract to maintain one-to-one relation between any key and subject. Keep an index of all primary and secondary keys, and check unique values during subject creation and key addition.