An application is a named schema hosted in a Doradus cluster. An application’s name is a unique identifier. An application’s data is stored in tables, which are isolated from other applications. A cluster can host multiple applications, and each application uses unique URIs to access its data. Example application names are Email and Magellan_1.Each application is defined in a schema. When the schema is first used to create the application, it is assigned to a specific storage manager. Depending on the Doradus server’s configuration, multiple storage managers may be available. An application’s schema can use core Doradus data model features plus extensions provided by the assigned storage service. Application schemas have the following components:
• Key: A user-defined string that acts as a secondary identifier. The key is optional and acts as an extra safety mechanism. If an application’s schema is defined with a key, the same key must be provided to modify the schema or delete the application.
• Options: The following application-level options can be defined:
• StorageService: Defines the storage service that will manage the application’s data.
• aging-check-frequency: Specifies the data aging check frequency for the application. The value of the aging-check-frequency must be in the form “<number> <units>” where <number> is a positive integer and <units> is MINUTES, HOURS, or DAYS. (Singular forms of these mnemonics are also allowed.) At the specified frequency, a background task looks for and deletes expired shards.
• auto-merge: Specifies a background task to check and automatically merge all shards for new data. The value of this option is the same as for the aging-check-frequency option: “<number> <units>”. Example: 1 HOUR. Task-based background merging is compatible with the Merge Shard REST command. That is, a shard can be manually merged even though background merging is occurring.
• Tables: Tables and their fields that the application owns.<application name="Email">{"Email": {