Closed gillespi314 closed 5 months ago
Regarding this @gillespi314 :
Additional considerations: How can we lint database migrations to detect migrations that impact tables with auto-updating timestamps?
I don't have a good automated solution for this, I see that the updated_at
timestamps are used extensively in stats, policies and labels, and in mdm setup assistant stuff. What I'd suggest going forward is for us to avoid extrapolating application-related meaning from this field - it represents the last time the row was updated - any data in that row -, period. If we need a timestamp to represent a more specific use-case (as in this case, the time the profile's content was uploaded/modified), a distinct field should be used. The created_at
/updated_at
should be seen as very basic, "mechanical" metadata.
For QA, @sabrinabuckets and @georgekarrv , if possible I'd say we should wait for next release (i.e. post-freeze) to merge this instead of rushing it in the upcoming one as a) it doesn't fix something that would be broken for users, it's a fix to avoid running into similar issues as we have recently, and b) it'd be good to have more time in QA for this fix to be around, to notice any weird behaviour around profiles delivery, as those can be tricky.
For QA (@sabrinabuckets ) I think that having some profiles in delivered state (Win+Apple) before applying the upgrade to this change and checking that they stay in delivered state (don't become failing or pending,etc.) would be a good check.
Verified DB schema changes and performed smoke testing as recommended.
MDM profiles rest, Timestamps no longer shift, Stability, our gift.
In the glass city, Code refactors bring calmness, Time's river slows, still.
Reflect in peace, now, Databases won't migrate wrong, Nature's quiet song.
Goal:
Prevent future database migrations from causing changes to auto-update timestamps for MDM profiles. See #15725.
How:
ON UPDATE CURRENT_TIMESTAMP
from theupdated_at
column.uploaded_at
.Additional considerations: