On 12/09/14 15:38, Jeremy Stanley wrote:
On 2014-09-12 11:54:19 +0200 (+0200), Daniel Izquierdo wrote:
And a question: was there a migration around the 2012-12-16 of the
review system or some other noticeable event?. On such date there
was around 1,200 submitted reviews, while around those days, in
mean, there are some dozens of them.
We discovered that Gerrit configures datestamps in most of its
tables to reset on row updates (a particularly insane design choice
for things like a "created_on" column). Before we realized this,
intrusive maintenance activities--most notably project renames--were
mass-resetting the creation dates of changes and comments to the
date and time we ran the necessary update queries. Now we
special-case those fields in our update queries to forcibly reset
them to themselves so that they retain their original values, but at
this point there's no easy way to go back and fix the ones we did
before we noticed this unfortunate loss of date/time information.
That makes totally sense, thanks a lot for the info!. Then we should try to avoid those reviews when calculating time to review and other time-based metrics.

This maintenance notification looks relevant...

Oops, thanks for the pointer. It's exactly that date (I didn't check the infra mailing list for that exactly date, my fault u_u).

Thanks a lot!


Daniel Izquierdo Cortazar, PhD
Chief Data Officer
"Software Analytics for your peace of mind"

OpenStack-dev mailing list

Reply via email to