Changes between Version 51 and Version 52 of Ticket #395


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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #395 – Description

    v51 v52  
    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. 
    88 
    9 If 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. 
     9If storing the incoming data fails an error status code of 500 should be returned to the client. If the database processing fails however the transaction should be rolled back but 200 OK should be returned to the client instead. This is to avoid re-transmission of the data, the error should be logged on the server however. 
    1010 
    1111Aggregation 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).