Skip to content

Application (Spider)

JoeWinter edited this page Mar 23, 2015 · 4 revisions

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


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: Application-level options (described below).

  • Tables: Tables and their fields that the application owns.

The general structure of a schema definition in XML is shown below:

<application name="Msgs">
	<key>MsgsKey</key>
	<options>
		// options
	</options>
	<tables>
		// table definitions
	</tables>
</application>

The general structure of a schema definition in JSON is shown below:

{"Msgs": {
	"key": "MsgsKey",
	"options": {
		// options
	},
	"tables": {
		// table definitions
	},
}}

Application Options

Doradus Spider supports the application-level option described below.

  • StorageService: All applications can explicitly choose their storage service by defining the application-level option StorageService. The storage service name for Spider applications is SpiderService. Example:

      <application name="Msgs">
      	<options>
      		<option name="StorageService" value="SpiderService"/>
      	</options>
      	...
      </application>
    

    If an application does not set the StorageService option, it is assigned the Doradus server default. Once assigned, the StorageService option cannot be changed.

  • AutoTables: Doradus Spider supports an application-level Boolean option called AutoTables, which is set to true by default. When enabled, AutoTables allows tables to be implicitly created when objects are added to them. For example, suppose the following Add Batch command is submitted:

    POST /Msgs/blogs

    If the blogs table does not exist and the Msgs application’s AutoTable option is true, the table is automatically created and then the Add Batch request is processed. An automatically-created table has no predefined fields, hence all field assignments are treated as dynamic Text fields. To disallow the automatic creation of tables, AutoTables must be set to false. Example:

      <application name="Msgs">
      	<key>MsgsKey</key>
      	<options>
      		<option name="AutoTables" value="false"/>
      	</options>
      	...
      </application>
    
  • aging-check-frequency: This option specifies a default data aging check frequency for all tables in the application that use data aging. Any table can override this option with a table-specific option. The value of the aging-check-frequency must be in the form “ ” where is a positive integer and is MINUTES, HOURS, or DAYS. (Singular forms of these mnemonics are also allowed.) The following example sets the default data aging check frequency to 1 day:

      <application name="Msgs">
      	<key>MsgsKey</key>
      	<options>
      		<option name="aging-check-frequency" value="false"/>
      	</options>
      	...
      </application>
    
Clone this wiki locally