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
In the db schema for Rosalind, the user_id field in the BatchUpdate model is defined as an integer, whereas it would need to be a string to accommodate the BSON ids coming from Gravity.
Since it's been defined as an integer the BSON ids are being truncated in the database, e.g.:
"548102be7261692d4ca00500" → 548102
(This is exactly analagous to the fix in 69ee68e, and I should have noticed that user_id would have been affected too)
I think the solution is pretty simple. We will
migrate the data type for that column
then replace the truncated IDs with the full ones
Luckily only a handful of users account for the ~200 batch updates that have been performed so far, so coming up with the mapping shouldn't be too hard.
The text was updated successfully, but these errors were encountered:
While investigating https://github.com/artsy/gravity/issues/11189 I noticed something that hadn't caught my attention before.
In the db schema for Rosalind, the
user_id
field in theBatchUpdate
model is defined as an integer, whereas it would need to be a string to accommodate the BSON ids coming from Gravity.Since it's been defined as an integer the BSON ids are being truncated in the database, e.g.:
"548102be7261692d4ca00500" → 548102
(This is exactly analagous to the fix in 69ee68e, and I should have noticed that
user_id
would have been affected too)I think the solution is pretty simple. We will
Luckily only a handful of users account for the ~200 batch updates that have been performed so far, so coming up with the mapping shouldn't be too hard.
The text was updated successfully, but these errors were encountered: