Spider REST Commands : Application Management Commands : Modify Application
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.