Datasets_DeleteDataset
const url = 'https://dev-api.qualiastudios.dev/v1/accounts/example/datasets/example';const options = {method: 'DELETE', headers: {'X-API-Key': '<X-API-Key>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request DELETE \ --url https://dev-api.qualiastudios.dev/v1/accounts/example/datasets/example \ --header 'X-API-Key: <X-API-Key>'Deletes a mixture, or retires an upload or a merged dataset: it leaves every list and its episodes leave every mixture, but nothing is erased, and versions that pin its episodes keep resolving. A merged dataset is retired with the uploads it holds (QUA-3511), which then answer NOT_FOUND; an upload bound to append to it that it does not hold (not appended yet, or taken back out before merges were final) is unbound. Refused with FAILED_PRECONDITION while another mixture reads it by name (for a merged dataset, also a pin of one of its uploads’ tags; any other source left on one of them reads nothing and does not hold it); a mixture that reads it through a label source stops reading it. An upload merged into another is not deleted on its own (FAILED_PRECONDITION naming the merged dataset). A dataset whose episodes are references of Tasks (Dataset.task_references) is refused too unless sent with force, which removes those references.
Authorizations
Section titled “Authorizations ”Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”The account id.
The dataset id.
Query Parameters
Section titled “Query Parameters ”The dataset’s current etag, when the caller wants the guard.
Delete it even though its episodes are references of Tasks (Dataset.task_references), removing those references; the Tasks stay. Without it, such a dataset is refused (FAILED_PRECONDITION). Reingests and the ingest report live under uploads and are never deleted here.
Responses
Section titled “ Responses ”OK
default
Section titled “default ”Default error response
The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. Each Status message contains three pieces of data: error code, error message, and error details. You can find out more about this error model and how to work with it in the API Design Guide.
object
The status code, which should be an enum value of [google.rpc.Code][google.rpc.Code].
A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the [google.rpc.Status.details][google.rpc.Status.details] field, or localized by the client.
A list of messages that carry the error details. There is a common set of message types for APIs to use.
Contains an arbitrary serialized message along with a @type that describes the type of the serialized message.
object
The type of the serialized message.
Example generated
{ "code": 1, "message": "example", "details": [ { "@type": "example" } ]}