Closed
Bug 1139713
Opened 9 years ago
Closed 9 years ago
[heartbeat] add a "last updated" field
Categories
(Input Graveyard :: Backend, defect, P1)
Input Graveyard
Backend
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: willkg, Assigned: willkg)
Details
(Whiteboard: u=gregg c=heartbeat p=2 s=input.2015q1)
The heartbeat Answer model has a lot of fields in it, but all of them come from the HB packet from the client including updated_ts. We have no field in the Answer model that represents the timestamp the server last updated the record. Since the updated_ts field is in "who knows what time", having a last updated field the server updates becomes super helpful. This bug covers adding one. Gregg: If I screwed up the description, kick me.
Assignee | ||
Comment 1•9 years ago
|
||
Grabbing this to work on ASAP.
Assignee: nobody → willkg
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•9 years ago
|
||
Gregg: I have two questions: 1. Is the description correct? 2. If so, what should we name the new column? Typically I use "updated", but I'm not sure if that gets confusing given we've got an "updated_ts" column that is completely different.
Flags: needinfo?(glind)
I might use received_ts, or server_ts, and describe it a "timestamp last version of the packet was received at the server". I see what you mean about updated though :/ . Clearly, this is a Wart and should be labeled as such!
Flags: needinfo?(glind)
Assignee | ||
Comment 4•9 years ago
|
||
In a PR: https://github.com/mozilla/fjord/pull/512
Assignee | ||
Comment 5•9 years ago
|
||
I screwed up and deleted the branch. Created a new PR: https://github.com/mozilla/fjord/pull/515
Assignee | ||
Comment 6•9 years ago
|
||
Landed in https://github.com/mozilla/fjord/commit/ff9f01c4d7deebd63029fa3b728e865d477bf946 Pushed to prod just now. But I screwed up the migration. PR to do another data migration: https://github.com/mozilla/fjord/pull/516
Assignee | ||
Comment 7•9 years ago
|
||
Fixed migration landed in https://github.com/mozilla/fjord/commit/d853fa91b5672002071f81924c3d507740c2f38e Pushed it, but it's an auto_now column, so all it did was spend a lot of time updating everything to now. Gregg: If you need me to, I can undo the auto_now part, redo the migration and then re-add the auto_now part. That'll get you received_ts times that are the updated_ts times for everything up to when I run the migration. Alternatively, we can just shrug our shoulders and shamble forwards with what we've got. Thoughts?
Flags: needinfo?(glind)
Assignee | ||
Comment 8•9 years ago
|
||
This took about a day.
Whiteboard: u=gregg c=heartbeat p= s=input.2015q1 → u=gregg c=heartbeat p=2 s=input.2015q1
Assignee | ||
Comment 9•9 years ago
|
||
Talked with Gregg. Future responses are more important than past responses, so I'm going to leave the received_ts field as is for past responses and call it a day. Closing this out now.
Flags: needinfo?(glind)
Assignee | ||
Comment 10•9 years ago
|
||
I meant to close this out. It's done!
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: Input → Input Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•