SuccessChanges

Summary

  1. Actually use the current time range for querying sections (commit: 1d30f3200aa183b15d062f5eb645e16451070f00) (details)
Commit 1d30f3200aa183b15d062f5eb645e16451070f00 by shankari
Actually use the current time range for querying sections
Doh! Without this, we keep inferring modes for the same sections over
and over.
Analysis below.
------------------------------------------------------------------------
Aha! we now have two copies of the analysis results
``` In [19]: edb.get_analysis_timeseries_db().find({"metadata.key":
"inference/prediction"},
   ...:  {"data.predicted_mode_map": "1"}).count() Out[19]: 137
In [20]: edb.get_analysis_timeseries_db().find({"metadata.key":
"analysis/inferred_secti
   ...: on"}, {"data.sensed_mode": "1"}).count() Out[20]: 137
In [21]: edb.get_analysis_timeseries_db().find({"metadata.key":
"analysis/inferred_secti
   ...: on"}, {"data.sensed_mode": "1"}).count() Out[21]: 274
In [22]: edb.get_analysis_timeseries_db().find({"metadata.key":
"inference/prediction"},
   ...:  {"data.predicted_mode_map": "1"}).count() Out[22]: 274
```
Let's figure out why?!
Ok so when we get to the MODE_INFERENCE stage, the `start_ts` is set
correctly.
``` 2018-02-26 10:03:41,381:INFO:140735691387712:For stage
PipelineStages.MODE_INFERENCE, start_ts = 2016-10-08T01:34:35.600000
```
But we still read all the sections again. Ah, the query doesn't appear
to involve the timestamp at all.
``` 2018-02-26 10:03:41,383:DEBUG:140735691387712:curr_query =
{'user_id': UUID('ea07ac60-0724-4eec-aab2-8240fcbf74ce'), '$or':
[{'metadata.key': 'analysis/cleaned_section'}]}, sort_key =
metadata.write_ts
```
(commit: 1d30f3200aa183b15d062f5eb645e16451070f00)
The file was modifiedemission/analysis/classification/inference/mode/pipeline.py (diff)