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
MongoDB has this fun quirk that ObjectIds are not comparable to string types when attempting aggregations. This is easy enough to fix when passing ID values directly to queries, I normally use a function to convert all ObjectId string types to real ObjectId type.
However, when the type is saved as a string and not an ObjectId, it's not obvious why comparing ID values within a doc (from events or projections), doesn't return any docs even though the actual string values are the same, but they aren't the right type.
I'm fixing this right now by making sure in aggregations to pass { $toObjectId: '$myProperty' }, but I think we could make this more convenient by storing them as real ObjectId values when storing in MongoDB.
The text was updated successfully, but these errors were encountered:
@alex-laycalvert sounds fair, but it'd be worth researching how others are handling it. The challenge that we may be facing are false positives. See the issue about (de)serialising BigInts: event-driven-io/Pongo#98
MongoDB has this fun quirk that
ObjectId
s are not comparable tostring
types when attempting aggregations. This is easy enough to fix when passing ID values directly to queries, I normally use a function to convert all ObjectId string types to realObjectId
type.However, when the type is saved as a
string
and not anObjectId
, it's not obvious why comparing ID values within a doc (from events or projections), doesn't return any docs even though the actual string values are the same, but they aren't the right type.I'm fixing this right now by making sure in aggregations to pass
{ $toObjectId: '$myProperty' }
, but I think we could make this more convenient by storing them as realObjectId
values when storing in MongoDB.The text was updated successfully, but these errors were encountered: