-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Integration
SERVER-99019 introduced the DocumentSource::Id type (an integer) and the ALLOCATE_DOCUMENT_SOURCE_ID() pre-processor macro, as a way of having a somewhat "dynamic modular enum". This allows server code to check what "kind of" DocumentSource any given DocumentSource* object is, without RTTI (which hurts performance) and without a centralized list of all possible DocumentSource types (eg. a giant static enum class, which hurts modularity).
This is good, but other code elsewhere in the server might want to use the same pattern, and as currently implemented, DocumentSource::Id and ALLOCATE_DOCUMENT_SOURCE_ID are too specific to help with that (at least based on how they're named).
This ticket is to generalize DocumentSource::Id and ALLOCATE_DOCUMENT_SOURCE_ID, so that the pattern they implement can be used anywhere in the server codebase.
To avoid needing to change boilerplate in all DocumentSource classes, the changes should happen "under the hood" of the DocumentSource::Id and ALLOCATE_DOCUMENT_SOURCE_ID API. That is, DocumentSource::Id and ALLOCATE_DOCUMENT_SOURCE_ID should remain, but their current implementation should be moved somewhere more general (eg. util/), and named more generically, and then DocumentSource::Id and ALLOCATE_DOCUMENT_SOURCE_ID changed so that they are merely consumers of this new "Generalized KindOf-Id" API.
Alternatively, we should check if the C++ STL or boost provide something like this, ie. a dynamically-allocated, immutable-after-allocation, efficient-allocation-and-comparison, type-safe enum. If so, it might be better to take advantage of that, rather than the homebrew DocumentSource::Id code, when defining and implementing the new "Generalized KindOf-Id" API. If such a thing isn't available, or is overly burdened in some way, then the homebrew code is still fine, since it's not especially complex.
An open question is whether there should be a separate "registry" (ie. a separate allocateId() function, each with its own counter) for each "consumer" of the generalized API, or whether it's fine to just have a single, global allocateId() for all consumers. The latter could be fine, since the Id type is unsigned long which is probably a sufficiently large "address space" for any single process.
- related to
-
SERVER-99019 Modularize DocumentSourceType
- Closed