Open Bug 1197813 Opened 4 years ago Updated Last year

[BZ ETL] Tracking flags changed corrupt bug history

Categories

(Testing :: General, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: ekyle, Unassigned)

References

(Blocks 2 open bugs)

Details

A database change does not record history. Renaming happened sometime before early August 2015.
Blocks: 959670
I'm not clear what the bug is here; is it just some cleanup in affected tools?
See Also: → 959670
See Also: 959670
See Also: → 997228
the see also bug describes the general problem
here's the entries from the audit_log table (so you have the exact timestamp):

user_id class                                           object_id field removed added at_time
5898    Bugzilla::Extension::TrackingFlags::Flag::Value 2127      value 3.0+    2.5+  2015-06-27 01:11:31
5898    Bugzilla::Extension::TrackingFlags::Flag::Value 2126      value 3.0?    2.5?  2015-06-27 01:11:31
Jonathan, 

From my naive standpoint, Bugzilla's historical record is complicated.  Bugzilla is primarily about storing bugs, and has a history table to track those changes.  It also has metadata, mostly lookup tables, with changes recorded in an `audit_log` table.  By recording the history of metadata, the `audit_log` is effectively capable of rewriting history, depending on your interpretation of what a change to the metadata means.  The `audit_log` was unknown to me when I built the bzETL because it is scrubbed of values when exported.

This bug is about incorporating the changes described in the audit_log to rebuild a better version of history.  There are three solutions I see so far:

1) Hard code these few exceptions 
2) Handle metadata changes, but manually fill a fake audit_log with the important changes
3) Handle the full audit log

I prefer #2 because I can record important changes in a format that will ensure the historical record is built properly.  We can see the audit_log refers to yet-more-tables: I am not certain the `class` column can even be found in the database, or what table(s) the `object_id` refers to.   For example, Byron's first entry is referring to changing all bugs with cf_tracking_b2g=='3.0+' to cf_tracking_b2g=='2.5+' 

ps

[1] #1 Will get messy fast
[2] #3 may be more coding than it is worth, especially since it refers to records in almost any table, and may never have been designed to rebuild history (and therefore never resolves the inconsistent historical record)
Blocks: 1201064
Kyle, I think this can be closed now given that B2G is history? Or would that apply to other components too? If yes, can you please update the summary?
Flags: needinfo?(klahnakoski)
Changed title from "b2g 3.0 renamed 2.5 with no history"
Flags: needinfo?(klahnakoski)
Summary: b2g 3.0 renamed 2.5 with no history → [BZ ETL] Tracking flags changed corrupt bug history
The logic to track pokes to the database has been started; the same logic as alias analysis might be used
You need to log in before you can comment on or make changes to this bug.