Application Management Commands (Spider)

[Table of Contents](https://github.com/dell-oss/Doradus/wiki/Spider Databases: Table-of-Contents) | Previous | Next
Spider REST Commands: Application Management Commands

---

REST commands that create, modify, and list applications are sent to the _applications resource. Application management REST commands supported by Doradus Spider are described in this section.

Create Application

A new application is created by sending a POST request to the _applications resource:

POST /_applications

The request must include the application’s schema as an input entity in XML or JSON format. If the request is successful, a 200 OK response is returned with no message body.

Because Doradus uses idempotent update semantics, using this command for an existing application is not an error and treated as a Modify Application command. If the identical schema is added twice, the second command is treated as a no-op.

See The MsgsSample Application section for an example schema in XML and JSON.

Modify Application

An existing application’s schema is modified with the following REST command:

POST /_application/{application}

where {application} is the application’s name. The request must include the modified schema in XML or JSON as specified by the request’s content-type header. Because an application’s name cannot be changed, {application} must match the application name in the schema. An application’s key cannot be changed either, hence if the application was defined with a key, the same key must be provided. If application was defined without a key, a key can be added by including it in the updated schema. If the request is successful, a 200 OK response is returned with no message body.

Modifying an application replaces its current schema. All schema changes are allowed, including adding and removing any schema component type, although there is no way to rename a schema component. However, minimal updates are made to accommodate changes to existing data. Various schema change scenarios and their data cleanup implications are summarized below:

• Adding a table: When a new table is added to the schema, the underlying stores (ColumnFamilies) are automatically created. Objects can be added to the table immediately after the schema change.

• Adding a new field: When a new scalar or link field is added, all existing objects will have a null value for the field. Data can be added to the field immediately after the schema change.

• Deleting a table: When an existing table is deleted, the corresponding stores (ColumnFamilies) are automatically deleted. However, if the table contains a link field whose extent table is not also deleted, inverse link data is not deleted. The obsolete link data, if present, is not returned in queries.

• Changing a field definition: All field modifications are allowed, but Spider does not automatically reorganize data to match the new field definition. For example, if a field’s type is changed from text to timestamp, existing data will remain indexed with the previous text-based analyzer.

• Deleting a field: When an existing scalar field is deleted, existing data is not disturbed, so it acts like an undefined field. The field’s existing values can be returned in queries, but the field can no longer be used as a grouping field in aggregate queries. When a link field (and its inverse) are deleted, existing link values are not deleted.

List Application

A list of all application schemas is obtained with the following command:

GET /_applications

The schemas are returned in the format specified by the Accept header.

The schema of a specific application is obtained with the following command:

GET /_applications/{application}

where {application} is the application’s name.

Delete Application

An existing application—including all of its data—is deleted with one the the following commands:

DELETE /_applications/{application}
DELETE /_applications/{application}/{key}`

where {application} is the application’s name. If the application’s schema defines a key, the {key} must be provided in the command, and it must match. When an application is deleted, all of its underlying stores (ColumnFamilies) are deleted.