ObjectId vs String _id consistency #758
Comments
|
Most importantly we want to work toward a state where they are of consistent type across the entire database - not necessarily all ObjectIds, but either all ObjectIds or all Strings. There may be big advantages to ObjectId, I'm not sure and will have to research that. But most databases should be able to index String IDs reasonably efficiently, especially at the scale of this application. I am not sure this is a case where we want to transition incrementally - it will be much easier to reason about if they are all the same type everywhere. I tend to see type fallbacks as another thing to go wrong. One problem we've encountered is that older object IDs may contain dashes or other non-hex digits. These can be stripped out to create new ObjectIds but we must update the names of any corresponding objects on S3. |
trevorgerhardt
added
p1
Eventually we'd like our database _id (and nonce) values to be ObjectIds, rather than Strings as was our longstanding practice, because we expect indexing and lookup to be more efficient.
As we incrementally make this transition, we should test to make sure that within a given collection, values are one type or the other.
We should also add more comments to specify which we expect in certain places, and consider fallback code in functions that may need to handle both. For example, if no records are found in the line here, we could try a lookup by the String _id (instead of the ObjectId) before returning?
r5/src/main/java/com/conveyal/analysis/persistence/AnalysisCollection.java
Line 63 in 0acf432
The text was updated successfully, but these errors were encountered: