You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One approach is to keep the ObjectIds as is in the DB, but use a frontend function to make it more readable. Any reduction in information could lead to more collisions, but I think this scheme will make it extremely unlikely:
Number in three parts, separated by hyphens, obtained from the timestamp embedded in ObjectId:
Number of days since outbreak (should be well-defined as we have OUTBREAK_DATE)
Number of seconds elapsed on the day in the timestamp, integer divided by 100, so this will go from 0 to 864
Last two bytes (0 - 65536) from incrementing number in the last block of ObjectId (A 3-byte incrementing counter, initialized to a random value)
Assuming an outbreak lasts upto 1000 days (3 years, which would be a pandemic, and thus unlikely to happen frequently), this would give a maximum number of digits as 11, while not touching the DB at all. In most cases, curators working on a single day’s cases would only need the second two bits as the number of days since outbreak would be the same.
This is assuming numerical IDs only, if we can do alphanumeric, we can shorten further by using hex or by using one of several naming systems such as https://pypi.org/project/human-id/ mapping UUIDs to a string of words; disadvantage is that alphanumeric systems usually lack monotonicity.
@abhidg Those are all great ideas! I think it all depends on Curator's preferences. @aimeehan1 is there any solution that works for you better than the other?
Currently cases are identified by default MongoDB IDs. We should make them shorter and easier to read for curators.
The text was updated successfully, but these errors were encountered: