One key feature of Rapture is that it is not restricted to any particular backing store; it can leverage multiple database technologies at the same time. As a result, the underlying implementation might not support a fast searchable index. To address this issue, each backing store can provide its own index mechanism. The intention is that the implementation can use native indexing where available, but that the indexing interface is abstracted. Note that only Mongo, Memory and Postgres implementations are available as of this release of the API. There is no indexing implementation for Cassandra.

HttpIndexApi indexApi = new HttpIndexApi(loginApi);
IndexConfig retVal = indexApi.createIndex(indexUri, config);

retVal = baseAPI.doIndex_CreateIndex(indexUri, config);

Entitlement: /admin/index/write

Generates a new index for the repository. Note that objects are indexed only when they are written. Any objects already in the repository are not automatically indexed; they need to be read and written back.

**

HttpIndexApi indexApi = new HttpIndexApi(loginApi);
IndexConfig retVal = indexApi.getIndex(indexUri);

retVal = baseAPI.doIndex_GetIndex(indexUri);

Entitlement: /admin/index/read

Gets the config for a specified index.

**

HttpIndexApi indexApi = new HttpIndexApi(loginApi);
void retVal = indexApi.deleteIndex(indexUri);

retVal = baseAPI.doIndex_DeleteIndex(indexUri);

Entitlement: /admin/index/write

Removes an index.

HttpIndexApi indexApi = new HttpIndexApi(loginApi);
TableQueryResult retVal = indexApi.findIndex(indexUri, query);

retVal = baseAPI.doIndex_FindIndex(indexUri, query);

Entitlement: /admin/index/read

findIndex uses a simple structure of the form SELECT (DISTINCT) field (,field...) WHERE condition (,condition...) (ORDER BY field (DESC) )Example: SELECT DISTINCT foo, bar WHERE baz = "wibble" ORDER BY foo

A subsection of a table that matches a given query.