how/when is rep_change updated?

Question

I am trying to determine the most efficient way to keep a user's rep_change history updated and need some guidance.

Here are a few assumptions that I am inferring from the available information:

1. the key for rep_change is post_id and user_id along with an implied site id
2. the on_date field is bumped when a rep related event for that post_id occurs

So, if I initialize a rep table with the user's complete rep history and save the time of the update, I can subsequently query /users/{id}/reputation with a fromdate equal to the last update and the results will contain all items that have had a rep change since fromdate - even if they have been returned in a previous update.

i.e.

• post #10 got a few upvotes when created last year and was entered into my local rep table at that time.
• the past xx number of rep updates have not contained that postid
• today, someone found post #10 and upvoted it and the on_date and positive_rep are updated
• the next time I query rep post #10 will be in the results and I can update the rep table using post_id (and user_id and contrived site_id) as key

Is this an accurate description?

No. and with clarification found in comment on accepted answer, understandably so.

Answer 1

Its probably easiest to think of this route as a view onto a users reputation graph.

+/- a user's questions/answers is returned, but the on_date is intentionally ambiguous. on_date ends up being the last voting event that occurred in a collapsed group. All votes on a post in a given period our collapsed based on post_id. No indication is given as to when any vote but the last one was made, nor whether it was an up or down vote.

user_id is returned because the route is vectorized, in that use-case you need to be able to map a returned value back to a user.

The key on the results (once de-vectorized, for lack of a better word) is the post_id. Though for caching purposes, you probably want to key on the [post_id, on_date]-tuple, with a caveat.

That caveat is that since the underlying votes are collapsed into [on_date, post_id]-tuples based on the queried window, you have to be aware of that window when updating your cache.

---

Be aware that depending on how you're using this data, conceptually, there's no guarantee that post_id is unique in the stream.