Page MenuHomePhabricator

Edit History: Review scala code functionality and make page and user output uniform
Closed, ResolvedPublic5 Story Points

Description

  • anyone who wants reviews the code and comment it
  • apply agreed changes to the code

Event Timeline

mforns created this task.Aug 18 2016, 3:47 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 18 2016, 3:47 PM
mforns set the point value for this task to 5.
mforns claimed this task.Aug 19 2016, 12:25 PM
mforns moved this task from Next Up to In Progress on the Analytics-Kanban board.

I reviewed the whole code looking for the things I believe we should tackle/decide before the vetting of the data, and made this list. Please comment if you think they are not important or should be tackled later on.

  • Both sides (user/page) of the code should output the errors or unexpected situations (or just statistics about them, counts). For example: parsing errors, events that can not join any history chain, history chains that get cropped because of conflicting events, etc. This would help measuring how much we actually reconstruct edit history and what differences to expect when comparing the data of Wikistats 1.0 vs 2.0.
  • Decide whether to use normalized titles/usernames or original ones in the output. Currently user->original, page->normalized.
  • Apply admin username historification on the page side.
  • Decide on: Flushing name-conflicting states only done when the current event joins with some state (page side). Or flushing name-conflicting states always regardless if the current event joins or not (user side).
  • Decide what default values give to: startTimestamp, registration/creation, causedByUserId, causedByUserName, causedByEventType when:
    • flushing state because its creation/registration is greater than current point in time.
    • flushing state because of name conflict with an upcoming event.
  • Confirm that we want to store deletion states (they kind of violate the unique title invariant, but as they have the type = delete, can be filtered out).
  • Decide whether we want to use the code structure of the user side also in the page side (with processingStatus) or not. This does not change the output, but may help applying all the other bullets in this list.

Following up with the conversation we had on the previous comment, these are the actions to take and implement in this task:

  1. outputting errors: By default, output counts on the errors, but add a flag argument that when set, outputs the whole errors to a file or somewhere.
  2. Leave it like it is, because it is the way mediawiki stores the username and pageTitle.
  3. We should remove the causedByUserName field from both sides of the algorithm and populate it in the SQL query that writes to the denormalized table.
  4. Always flush conflicting states. Better incomplete than incorrect.
  5. When flushing, default to type="create", start=evt.ts, creation=evt.ts, causedByUserId=None, and add a new field that stores that some values are a guess.
  6. Leave delete states as they are.
  7. Do not change the structure of the pageHistoryBuilder, if we need, we can change it when more event types come.
mforns moved this task from In Progress to Done on the Analytics-Kanban board.Aug 25 2016, 9:40 PM
Nuria closed this task as Resolved.Sep 1 2016, 3:03 PM