#[non_exhaustive]
pub enum ExportTableToPointInTimeErrorKind {
ExportConflictException(ExportConflictException),
InternalServerError(InternalServerError),
InvalidExportTimeException(InvalidExportTimeException),
LimitExceededException(LimitExceededException),
PointInTimeRecoveryUnavailableException(PointInTimeRecoveryUnavailableException),
TableNotFoundException(TableNotFoundException),
Unhandled(Unhandled),
}
Expand description
Types of errors that can occur for the ExportTableToPointInTime
operation.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
ExportConflictException(ExportConflictException)
There was a conflict when writing to the specified S3 bucket.
InternalServerError(InternalServerError)
An error occurred on the server side.
InvalidExportTimeException(InvalidExportTimeException)
The specified ExportTime
is outside of the point in time recovery window.
LimitExceededException(LimitExceededException)
There is no limit to the number of daily on-demand backups that can be taken.
For most purposes, up to 500 simultaneous table operations are allowed per account. These operations include CreateTable
, UpdateTable
, DeleteTable
,UpdateTimeToLive
, RestoreTableFromBackup
, and RestoreTableToPointInTime
.
When you are creating a table with one or more secondary indexes, you can have up to 250 such requests running at a time. However, if the table or index specifications are complex, then DynamoDB might temporarily reduce the number of concurrent operations.
When importing into DynamoDB, up to 50 simultaneous import table operations are allowed per account.
There is a soft account quota of 2,500 tables.
Point in time recovery has not yet been enabled for this source table.
TableNotFoundException(TableNotFoundException)
A source table with the name TableName
does not currently exist within the subscriber's account or the subscriber is operating in the wrong Amazon Web Services Region.
Unhandled(Unhandled)
An unexpected error occurred (e.g., invalid JSON returned by the service or an unknown error code).
When logging an error from the SDK, it is recommended that you either wrap the error in
DisplayErrorContext
, use another
error reporter library that visits the error’s cause/source chain, or call
Error::source
for more details about the underlying cause.