Skip to content

write_records async

write_records(
    database_name: ResourceName,
    table_name: ResourceName,
    records: Records,
    *,
    config_overrides: Optional[AsyncTimestreamWriteClientConfig] = None,
    common_attributes: Optional[Record] = None,
) -> WriteRecordsResponse

Enables you to write your time-series data into Timestream. You can specify a single data point or a batch of data points to be inserted into the system. Timestream offers you a flexible schema that auto detects the column names and data types for your Timestream tables based on the dimension names and data types of the data points you specify when invoking writes into the database.

Timestream supports eventual consistency read semantics. This means that when you query data immediately after writing a batch of data into Timestream, the query results might not reflect the results of a recently completed write operation. The results may also include some stale data. If you repeat the query request after a short time, the results should return the latest data. Service quotas apply.

See code sample for details.

Upserts

You can use the Version parameter in a WriteRecords request to update data points. Timestream tracks a version number with each record. Version defaults to 1 when it's not specified for the record in the request. Timestream updates an existing record’s measure value along with its Version when it receives a write request with a higher Version number for that record. When it receives an update request where the measure value is the same as that of the existing record, Timestream still updates Version, if it is greater than the existing value of Version. You can update a data point as many times as desired, as long as the value of Version continuously increases.

For example, suppose you write a new record without indicating Version in the request. Timestream stores this record, and set Version to 1. Now, suppose you try to update this record with a WriteRecords request of the same record with a different measure value but, like before, do not provide Version. In this case, Timestream will reject this update with a RejectedRecordsException since the updated record’s version is not greater than the existing value of Version.

However, if you were to resend the update request with Version set to 2, Timestream would then succeed in updating the record’s value, and the Version would be set to 2. Next, suppose you sent a WriteRecords request with this same record and an identical measure value, but with Version set to 3. In this case, Timestream would only update Version to 3. Any further updates would need to send a version number greater than 3, or the update requests would receive a RejectedRecordsException.

Parameters:

  • database_name (ResourceName) –

    The name of the Timestream database.

  • table_name (ResourceName) –

    The name of the Timestream table.

  • common_attributes (Optional[Record], default: None ) –

    A record that contains the common measure, dimension, time, and version attributes shared across all the records in the request. The measure and dimension attributes specified will be merged with the measure and dimension attributes in the records object when the data is written into Timestream. Dimensions may not overlap, or a ValidationException will be thrown. In other words, a record must contain dimensions with unique names.

  • records (Records) –

    An array of records that contain the unique measure, dimension, time, and version attributes for each time-series data point.

Raises:

  • AccessDeniedException –

    You are not authorized to perform this action.

  • InternalServerException –

    Timestream was unable to fully process this request because of an internal server error.

  • InvalidEndpointException –

    The requested endpoint was not valid.

  • RejectedRecordsException –

    WriteRecords would throw this exception in the following cases:

    • Records with duplicate data where there are multiple records with the same dimensions, timestamps, and measure names but:

      • Measure values are different

      • Version is not present in the request or the value of version in the new record is equal to or lower than the existing value

      In this case, if Timestream rejects data, the ExistingVersion field in the RejectedRecords response will indicate the current record’s version. To force an update, you can resend the request with a version for the record set to a value greater than the ExistingVersion.

    • Records with timestamps that lie outside the retention duration of the memory store.

    • Records with dimensions or measures that exceed the Timestream defined limits.

    For more information, see Quotas in the Amazon Timestream Developer Guide.

  • ResourceNotFoundException –

    The operation tried to access a nonexistent resource. The resource might not be specified correctly, or its status might not be ACTIVE.

  • ThrottlingException –

    Too many requests were made by a user and they exceeded the service quotas. The request was throttled.

  • ValidationException –

    An invalid or malformed request.

  • UnknownServiceError –

    The service returned an error code this client does not model.

Source code in docs_src/capo_timestream_write/_services/async_timestream_write.py
async def write_records(
    self,
    database_name: "capo_timestream_write.types.resource_name.ResourceName",
    table_name: "capo_timestream_write.types.resource_name.ResourceName",
    records: "capo_timestream_write.types.records.Records",
    *,
    config_overrides: Optional[AsyncTimestreamWriteClientConfig] = None,
    common_attributes: Optional["capo_timestream_write.types.record.Record"] = None,
) -> "capo_timestream_write.types.write_records_response.WriteRecordsResponse":
    """<p>Enables you to write your time-series data into Timestream. You can specify a single data point or a batch of data points to be inserted into the system. Timestream offers you a flexible schema that auto detects the column names and data types for your Timestream tables based on the dimension names and data types of the data points you specify when invoking writes into the database. </p> <p>Timestream supports eventual consistency read semantics. This means that when you query data immediately after writing a batch of data into Timestream, the query results might not reflect the results of a recently completed write operation. The results may also include some stale data. If you repeat the query request after a short time, the results should return the latest data. <a href="https://docs.aws.amazon.com/timestream/latest/developerguide/ts-limits.html">Service quotas apply</a>. </p> <p>See <a href="https://docs.aws.amazon.com/timestream/latest/developerguide/code-samples.write.html">code sample</a> for details.</p> <p> <b>Upserts</b> </p> <p>You can use the <code>Version</code> parameter in a <code>WriteRecords</code> request to update data points. Timestream tracks a version number with each record. <code>Version</code> defaults to <code>1</code> when it's not specified for the record in the request. Timestream updates an existing record’s measure value along with its <code>Version</code> when it receives a write request with a higher <code>Version</code> number for that record. When it receives an update request where the measure value is the same as that of the existing record, Timestream still updates <code>Version</code>, if it is greater than the existing value of <code>Version</code>. You can update a data point as many times as desired, as long as the value of <code>Version</code> continuously increases. </p> <p> For example, suppose you write a new record without indicating <code>Version</code> in the request. Timestream stores this record, and set <code>Version</code> to <code>1</code>. Now, suppose you try to update this record with a <code>WriteRecords</code> request of the same record with a different measure value but, like before, do not provide <code>Version</code>. In this case, Timestream will reject this update with a <code>RejectedRecordsException</code> since the updated record’s version is not greater than the existing value of Version. </p> <p>However, if you were to resend the update request with <code>Version</code> set to <code>2</code>, Timestream would then succeed in updating the record’s value, and the <code>Version</code> would be set to <code>2</code>. Next, suppose you sent a <code>WriteRecords</code> request with this same record and an identical measure value, but with <code>Version</code> set to <code>3</code>. In this case, Timestream would only update <code>Version</code> to <code>3</code>. Any further updates would need to send a version number greater than <code>3</code>, or the update requests would receive a <code>RejectedRecordsException</code>. </p>

    Args:
        database_name: <p>The name of the Timestream database.</p>
        table_name: <p>The name of the Timestream table.</p>
        common_attributes: <p>A record that contains the common measure, dimension, time, and version attributes shared across all the records in the request. The measure and dimension attributes specified will be merged with the measure and dimension attributes in the records object when the data is written into Timestream. Dimensions may not overlap, or a <code>ValidationException</code> will be thrown. In other words, a record must contain dimensions with unique names. </p>
        records: <p>An array of records that contain the unique measure, dimension, time, and version attributes for each time-series data point. </p>

    Raises:
        capo_timestream_write.errors.access_denied_exception.AccessDeniedException: <p>You are not authorized to perform this action.</p>
        capo_timestream_write.errors.internal_server_exception.InternalServerException: <p> Timestream was unable to fully process this request because of an internal server error.</p>
        capo_timestream_write.errors.invalid_endpoint_exception.InvalidEndpointException: <p>The requested endpoint was not valid.</p>
        capo_timestream_write.errors.rejected_records_exception.RejectedRecordsException: <p> WriteRecords would throw this exception in the following cases: </p> <ul> <li> <p>Records with duplicate data where there are multiple records with the same dimensions, timestamps, and measure names but: </p> <ul> <li> <p>Measure values are different</p> </li> <li> <p>Version is not present in the request <i>or</i> the value of version in the new record is equal to or lower than the existing value</p> </li> </ul> <p> In this case, if Timestream rejects data, the <code>ExistingVersion</code> field in the <code>RejectedRecords</code> response will indicate the current record’s version. To force an update, you can resend the request with a version for the record set to a value greater than the <code>ExistingVersion</code>.</p> </li> <li> <p> Records with timestamps that lie outside the retention duration of the memory store. </p> </li> <li> <p> Records with dimensions or measures that exceed the Timestream defined limits. </p> </li> </ul> <p> For more information, see <a href="https://docs.aws.amazon.com/timestream/latest/developerguide/ts-limits.html">Quotas</a> in the Amazon Timestream Developer Guide. </p>
        capo_timestream_write.errors.resource_not_found_exception.ResourceNotFoundException: <p>The operation tried to access a nonexistent resource. The resource might not be specified correctly, or its status might not be ACTIVE.</p>
        capo_timestream_write.errors.throttling_exception.ThrottlingException: <p> Too many requests were made by a user and they exceeded the service quotas. The request was throttled.</p>
        capo_timestream_write.errors.validation_exception.ValidationException: <p> An invalid or malformed request.</p>
        capo_timestream_write.errors.UnknownServiceError: The service returned an error code this client does not model.
    """

    async def _handler(
        req: "AsyncOperationRequest[capo_timestream_write.types.write_records_request.WriteRecordsRequest]",
    ) -> AsyncOperationResponse[
        "capo_timestream_write.types.write_records_response.WriteRecordsResponse"
    ]:
        import capo_timestream_write._operations.timestream_20181101.write_records

        (
            output,
            http_response,
        ) = await capo_timestream_write._operations.timestream_20181101.write_records.async_write_records(
            req.options, req.input
        )
        return AsyncOperationResponse(output=output, response=http_response)

    interceptors_, options_ = self.operation_options(
        config_overrides, OperationLogging("WriteRecords")
    )
    input_: capo_timestream_write.types.write_records_request.WriteRecordsRequest = {
        "database_name": database_name,
        "table_name": table_name,
        "records": records,
    }
    if common_attributes is not None:
        input_["common_attributes"] = common_attributes

    response = await aexecute_pipeline(
        AsyncOperationRequest(input=input_, options=options_),
        handler=_handler,
        interceptors=list(interceptors_),
    )
    await response.response.aclose()
    return response.output