Changes between Version 48 and Version 51 of Ticket #395


Ignore:
Timestamp:
12/17/2014 10:27:03 PM (5 years ago)
Author:
kzar
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #395 – Description

    v48 v51  
    66 
    77Note that we can receive the data and store + process it immediately, even though this approach will delay processing of the request. The request is sent by the browser in the background, so the user doesn't care about processing times. We can still switch to a more elaborate approach later. 
     8 
     9If logging the data files an error status code of 500 should be returned. If the database processing fails however the transaction should be rolled back and 200 OK should be returned to the client to avoid re-transmission of the data. The error should be logged on the server however so that we know there is a problem. 
    810 
    911Aggregation approach is complicated by the fact that clients will submit data that was collected over different time intervals. We want to use geometrical mean for now, but this is merely a placeholder for a better approach. Let's say we have stored in the database (for a particular filter and domain): `numclicks = 7`, `timestamp = 123`. We receive `numclicks = 2`, `timestamp = 128`. So the timestamp difference is 5. We update the record: `numclicks = 7 ^ (1 - 5 / interval) * 2 ^ (5 / interval)` and `timestamp = 128`. Here `interval` is a constant that will determine how fast old values expire, it probably makes sense to set it equal to the push interval on the client (meaning e.g. 1 week).