Skip to content
CARP Documentation

DataPointReference

A reference to the legacy data point endpoint of one study deployment in CAWS.

Obtained from the deprecated CarpService.dataPointReference. New code uploads data with CarpDataStreamService instead.

Can be used to:

Inheritance

Properties

dataEndpointUri

String get dataEndpointUri

The URL of the data point endpoint for this DataPointReference.

fileCachePath

Future<String> get fileCachePath

The local folder where batch writes files before upload.

Uses the cache path of Settings for this deployment if Settings is initialized, otherwise cache/upload. Created if missing.

studyDeploymentId

String get studyDeploymentId

The study deployment id of this data point reference.

Methods

batch

Future<void> batch(
  1. List<DataPoint> batch
)

Batch uploads a list of DataPoints.

The list is written to a JSON file in fileCachePath and sent with upload. The file is not deleted afterwards.

count

Future<int> count([
  1. String query = ''
])

The number of data points matching the query for this deployment.

A query using REST SQL (RSQL) can be provided.

delete

Future<void> delete(
  1. int id
)

Deletes a data point with the given id.

Returns on success. Throws a CarpServiceException if data point is not found or otherwise unsuccessful.

get

Future<DataPoint> get(
  1. int id
)

Gets a DataPoint based on its id from CAWS.

getAll

Future<List<DataPoint>> getAll()

Gets all DataPoints for this study deployment.

Be careful using this method - this might potential return an enormous amount of data.

post

Future<int> post(
  1. DataPoint data
)

Uploads data.

Returns the server-generated ID for this data point.

query

Future<List<DataPoint>> query(
  1. String query
)

Queries for DataPoints in CAWS using REST SQL (RSQL).

The query string can be build by querying data point fields using logical operations.

Query fields can be any field in a data point JSON, including nested fields. Examples include:

  • Data point fields such as id, study_id and created_at.
  • Header fields such as carp_header.start_time, carp_header.user_id, and carp_header.data_format.name
  • Body fields such as carp_body.latitude or carp_body.connectivity_status

Note that field names are nested using the dot-notation.

See here for details on grammar and semantic.

The logical operations include:

  • Logical AND : ; or and
  • Logical OR : , or or

Comparison operations include.

  • Equal to : ==
  • Not equal to : !=
  • Less than : =lt= or <
  • Less than or equal to : =le= or <=
  • Greater than operator : =gt= or >
  • Greater than or equal to : =ge= or >=
  • In : =in=
  • Not in : =out=

Examples of query strings include:

Get all data-points between 2018-05-27T13:28:07 and 2019-05-29T08:55:26

  • carp_header.created_at>2018-05-27T13:28:07Z;carp_header.created_at<2019-05-29T08:55:26Z

Get all where the user id is 1 or 2

  • carp_header.user_id==1,2

Below is an example of a data point in JSON to see the different fields.

{
  "id": 24481799,
  "study_id": 2,
  "created_by_user_id": 2,
  "created_at": "2019-06-19T09:50:44.245Z",
  "updated_at": "2019-06-19T09:50:44.245Z",
  "carp_header": {
    "study_id": "8",
    "user_id": "user@dtu.dk",
    "data_format": {
      "name": "location",
      "namepace": "carp"
    },
    "trigger_id": "task1",
    "device_role_name": "Patient's phone",
    "upload_time": "2019-06-19T09:50:43.551Z",
    "start_time": "2018-11-08T15:30:40.721748Z",
    "end_time": "2019-06-19T09:50:43.551Z"
  },
  "carp_body": {
    "altitude": 43.3,
    "device_info": {},
    "classname": "LocationDatum",
    "latitude": 23454.345,
    "accuracy": 12.4,
    "speed_accuracy": 12.3,
    "id": "3fdd1760-bd30-11e8-e209-ef7ee8358d2f",
    "speed": 2.3,
    "timestamp": "2018-11-08T15:30:40.721748Z",
    "longitude": 23.4
  }
 }

upload

Future<void> upload(
  1. File file
)

Batch uploads the file containing a list of DataPoints to CAWS.

The file can be created using a FileDataManager in carp_mobile_sensing. Note that the file should be raw JSON, and hence not zipped.

The request is sent in the background with retry; the returned future completes before the upload does, so upload errors are not passed to the caller.