Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a new method to store data synchronously #687

Merged
merged 1 commit into from
May 9, 2019

Conversation

shankari
Copy link
Contributor

@shankari shankari commented May 9, 2019

This is intended for foreground use only, primarily to synchronously save
user inputs in case we need it for server-specific services (e.g. generating a
suggestion) or in case we want to ensure that the data is saved before the app
is uninstalled.

Since it is used in the foreground, users can be interactively notified if the
save failed.

In order to reduce abuse for sending background sensed data, this can accept one entry at a time.

For client integrators, as you can see, this is similar to /profile/update, but the data is under the_entry instead of update_doc

Testing done:

We have 76 entries

In [16]: edb.get_usercache_db().find({"metadata.key": "manual/mode_confirm"}).count()
Out[16]: 76

We save one more

In [17]: test_input = {
    ...:   "user": "test_mode_purpose",
    ...:   "the_entry" : {
    ...:      "metadata": {"key": "manual/mode_confirm", "write_ts": 12345678, "type": "
    ...: message"},
    ...:      "data": {"start_ts": 1234, "end_ts": 5678, "label": "pogo_sticking"}
    ...:   }
    ...: }

In [18]: requests.post("http://localhost:8080/usercache/putone", data=json.dumps(test_in
    ...: put), headers=headers)
Out[18]: <Response [200]>
START 2019-05-08 19:17:35.633951 POST /usercache/putone
END 2019-05-08 19:17:35.649836 POST /usercache/putone 49e72fc4-f1d8-4f4d-9666-57dc597d1133 0.015433073043823242

We now have 77 entries

In [19]: edb.get_usercache_db().find({"metadata.key": "manual/mode_confirm"}).count()
Out[19]: 77

and the new one is the right one

In [20]: edb.get_usercache_db().find({"metadata.key": "manual/mode_confirm", "data.label
    ...: ": "pogo_sticking"}).count()
Out[20]: 1

In [21]: edb.get_usercache_db().find_one({"metadata.key": "manual/mode_confirm", "data.l
    ...: abel": "pogo_sticking"})
Out[21]:
{'_id': ObjectId('5cd38dbfbe04ee70f576335d'),
 'data': {'end_ts': 5678, 'label': 'pogo_sticking', 'start_ts': 1234},
 'metadata': {'key': 'manual/mode_confirm',
  'type': 'message',
  'write_ts': 12345678},
 'user_id': UUID('49e72fc4-f1d8-4f4d-9666-57dc597d1133')}

This also fixes e-mission/e-mission-docs#351 in a
more principled way.

This is intended for **foreground use only**, primarily to synchronously save
user inputs in case we need it for server-specific services (e.g. generating a
suggestion) or in case we want to ensure that the data is saved before the app
is uninstalled.

Since it is used in the foreground, users can be interactively notified if the
save failed.

In order to reduce abuse for sending background sensed data, this can accept one entry at a time.

For client integrators, as you can see, this is similar to `/profile/update`, but the data is under `the_entry` instead of `update_doc`

Testing done:

We have 76 entries

```
In [16]: edb.get_usercache_db().find({"metadata.key": "manual/mode_confirm"}).count()
Out[16]: 76
```

We save one more

```
In [17]: test_input = {
    ...:   "user": "test_mode_purpose",
    ...:   "the_entry" : {
    ...:      "metadata": {"key": "manual/mode_confirm", "write_ts": 12345678, "type": "
    ...: message"},
    ...:      "data": {"start_ts": 1234, "end_ts": 5678, "label": "pogo_sticking"}
    ...:   }
    ...: }

In [18]: requests.post("http://localhost:8080/usercache/putone", data=json.dumps(test_in
    ...: put), headers=headers)
Out[18]: <Response [200]>
```

```
START 2019-05-08 19:17:35.633951 POST /usercache/putone
END 2019-05-08 19:17:35.649836 POST /usercache/putone 49e72fc4-f1d8-4f4d-9666-57dc597d1133 0.015433073043823242
```

We now have 77 entries

```
In [19]: edb.get_usercache_db().find({"metadata.key": "manual/mode_confirm"}).count()
Out[19]: 77
```

and the new one is the right one

```
In [20]: edb.get_usercache_db().find({"metadata.key": "manual/mode_confirm", "data.label
    ...: ": "pogo_sticking"}).count()
Out[20]: 1

In [21]: edb.get_usercache_db().find_one({"metadata.key": "manual/mode_confirm", "data.l
    ...: abel": "pogo_sticking"})
Out[21]:
{'_id': ObjectId('5cd38dbfbe04ee70f576335d'),
 'data': {'end_ts': 5678, 'label': 'pogo_sticking', 'start_ts': 1234},
 'metadata': {'key': 'manual/mode_confirm',
  'type': 'message',
  'write_ts': 12345678},
 'user_id': UUID('49e72fc4-f1d8-4f4d-9666-57dc597d1133')}
```

This also fixes e-mission/e-mission-docs#351 in a
more principled way.
@AmplabJenkins
Copy link

Merged build finished. Test FAILed.

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/e-mission-server-prb/1103/
Test FAILed.

@shankari
Copy link
Contributor Author

shankari commented May 9, 2019

jenkins test this please

@shankari
Copy link
Contributor Author

shankari commented May 9, 2019

jenkins, test this please

@AmplabJenkins
Copy link

Merged build finished. Test PASSed.

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/e-mission-server-prb/1105/
Test PASSed.

@shankari shankari merged commit f40fc5f into e-mission:master May 9, 2019
@shankari shankari deleted the add_sync_update_method branch May 14, 2019 01:38
jf87 pushed a commit to jf87/e-mission-server that referenced this pull request Jun 21, 2021
Add a new method to store data synchronously
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Asking users for mode and purpose confirmation at the end of a study is problematic
2 participants