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":
   ...:  {"data.predicted_mode_map": "1"}).count() Out[19]: 137
In [20]: edb.get_analysis_timeseries_db().find({"metadata.key":
   ...: on"}, {"data.sensed_mode": "1"}).count() Out[20]: 137
In [21]: edb.get_analysis_timeseries_db().find({"metadata.key":
   ...: on"}, {"data.sensed_mode": "1"}).count() Out[21]: 274
In [22]: edb.get_analysis_timeseries_db().find({"metadata.key":
   ...:  {"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
``` 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 =
(commit: 1d30f3200aa183b15d062f5eb645e16451070f00)
The file was modifiedemission/analysis/classification/inference/mode/ (diff)