-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DemoStoage
should not choose its initial oid randomly
#401
Comments
|
Dieter, thanks for raising this up. I agree with your analysis. For the reference: in ZODB/go demo storage verifies that its base stays constant and shutdowns itself if it detects base change: https://lab.nexedi.com/kirr/neo/-/blob/ee23551d/go/zodb/storage/demo/demo.go#L91-141 Kirill |
BUG/PROBLEM REPORT / FEATURE REQUEST
Any storage must guarantee that different objects get different oids.
Most storages achieve this by starting with oid
0
and generating new oids sequentially in a synchronized (uninterruptable) operation.DemoStorage
layers aMappingStorage
on top of any storage, its "base storage". Usually, the base storage already has assigned some oids, andDemoStorage
must not assign those oids again for new objects. It chooses its starting oid randomly (random.randint(1, 1 << 62)
). While this usually gives new objects new oids, it can fail non-deterministically.The most natural choice for a
DemoStorage
's initial oid would be the next oid of its base storage (and prevent the base storage to assign new oids itself). However, this may interfere with a use case forDemoStorage
: support a demo on a life (independently changed) storage.I therefore suggest to choose the initial oid as the base's
next_oid
plus0x100000000
. This allows the base storage to create about4 * 10 ** 9
objects before its independent oid generation may conflict with that of theDemoStorage
on top -- which should be sufficient for any practical case.The text was updated successfully, but these errors were encountered: