This is the second time we have this problem. We adjusted a calculation in a stored, indexed calculation field of the source file. I can’t remember if the first time was in the same type of field, it probably was.
So when we migrate that version to production, this weird thing happens where the value in the field is good and was adjusted by the new function, but the index is not. Not in the way that it’s simply the old value… For example, in this case, perform find of “10” in this number field returns records of 10 but also 11. This is at least consistent with what the value was before, but the result of the query is just so random, like half and half.
If we drop the index and let it build automatically again, everything is fine, 10 finds 10 and 11 finds 11.
Does anyone know of maybe a more specific cause we could prevent? If not, would our only way to insure this doesn’t happen again is leaving “Re-build indexes” to yes? I kinda don’t want this overhead that is usually useless. Should we simply say to every dev to not use stored calculations because we use the data migration tool?