mirror of https://gitee.com/bigwinds/arangodb
ArangoSearch refactor (3.5) (#9597)
* Correct View Creation object struct (WIP) * 404 -> 409, remove old note * Remove unnecessary DocuBlocks, uppercase Views * field-name has object value * Add missing View props, unify * Remove line break * Remove subtype for consolidationPolicy * Indent list * attempt to fix fields / field-name * remove links @RESTSTRUCTs and point to docs Note: this uses an absolute link in order to work in Swagger
This commit is contained in:
Simran
KVS85
parent
5a20828210
commit
73932a784b
|
|
@ -1,20 +1,20 @@
|
|||
@startDocuBlock delete_api_view
|
||||
@brief drops a view
|
||||
@brief drops a View
|
||||
|
||||
@RESTHEADER{DELETE /_api/view/{view-name}, Drops a view, deleteView}
|
||||
@RESTHEADER{DELETE /_api/view/{view-name}, Drops a View, deleteView}
|
||||
|
||||
@RESTURLPARAMETERS
|
||||
|
||||
@RESTURLPARAM{view-name,string,required}
|
||||
The name of the view to drop.
|
||||
The name of the View to drop.
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Drops the view identified by *view-name*.
|
||||
Drops the View identified by *view-name*.
|
||||
|
||||
If the view was successfully dropped, an object is returned with
|
||||
the following attributes:
|
||||
- *error*: *false*
|
||||
- *id*: The identifier of the dropped view
|
||||
- *id*: The identifier of the dropped View
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
|
|
@ -28,7 +28,7 @@ If the *view-name* is unknown, then a *HTTP 404* is returned.
|
|||
|
||||
Using an identifier:
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewDeleteViewIdentifier}
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewDeleteViewIdentifierArangoSearch}
|
||||
var viewName = "testView";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ Using an identifier:
|
|||
|
||||
Using a name:
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewDeleteViewName}
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewDeleteViewNameArangoSearch}
|
||||
var viewName = "testView";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
|
|
|
|||
|
|
@ -1,18 +1,18 @@
|
|||
@startDocuBlock get_api_view_name
|
||||
@brief returns a view
|
||||
@brief returns a View
|
||||
|
||||
@RESTHEADER{GET /_api/view/{view-name}, Return information about a view, getViews:Properties}
|
||||
@RESTHEADER{GET /_api/view/{view-name}, Return information about a View, getViews:Properties}
|
||||
|
||||
@RESTURLPARAMETERS
|
||||
|
||||
@RESTURLPARAM{view-name,string,required}
|
||||
The name of the view.
|
||||
The name of the View.
|
||||
|
||||
@RESTDESCRIPTION
|
||||
The result is an object describing the view with the following attributes:
|
||||
- *id*: The identifier of the view
|
||||
- *name*: The name of the view
|
||||
- *type*: The type of the view as string
|
||||
The result is an object briefly describing the View with the following attributes:
|
||||
- *id*: The identifier of the View
|
||||
- *name*: The name of the View
|
||||
- *type*: The type of the View as string
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
|
|
@ -23,7 +23,7 @@ If the *view-name* is unknown, then a *HTTP 404* is returned.
|
|||
|
||||
Using an identifier:
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewGetViewIdentifier}
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewGetViewIdentifierArangoSearch}
|
||||
var viewName = "testView";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ Using an identifier:
|
|||
|
||||
Using a name:
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewGetViewName}
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewGetViewNameArangoSearch}
|
||||
var viewName = "testView";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
@startDocuBlock get_api_view_properties
|
||||
@brief reads the properties of the specified view
|
||||
@brief reads the properties of the specified View
|
||||
|
||||
@RESTHEADER{GET /_api/view/{view-name}/properties, Read properties of a view, getView}
|
||||
@RESTHEADER{GET /_api/view/{view-name}/properties, Read properties of a View, getView}
|
||||
|
||||
@RESTURLPARAMETERS
|
||||
|
||||
|
|
@ -9,14 +9,11 @@
|
|||
Returns an object containing the definition of the view identified by *view-name*.
|
||||
|
||||
@RESTURLPARAM{view-name,string,required}
|
||||
The name of the view.
|
||||
The name of the View.
|
||||
|
||||
@RESTDESCRIPTION
|
||||
The result is an object describing the view with the following attributes:
|
||||
- *id*: The identifier of the view
|
||||
- *name*: The name of the view
|
||||
- *type*: The type of the view as string
|
||||
- any additional view implementation specific properties
|
||||
The result is an object with a full description of a specific View, including
|
||||
View type dependent properties.
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
|
|
@ -30,7 +27,7 @@ If the *view-name* is unknown, then a *HTTP 404* is returned.
|
|||
|
||||
Using an identifier:
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewGetViewPropertiesIdentifier}
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewGetViewPropertiesIdentifierArangoSearch}
|
||||
var viewName = "products";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
|
|
@ -47,7 +44,7 @@ Using an identifier:
|
|||
|
||||
Using a name:
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewGetViewPropertiesName}
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewGetViewPropertiesNameArangoSearch}
|
||||
var viewName = "products";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
|
|
|
|||
|
|
@ -1,19 +1,23 @@
|
|||
@startDocuBlock get_api_views
|
||||
@brief returns all views
|
||||
@brief returns all Views
|
||||
|
||||
@RESTHEADER{GET /_api/view, List all views, getViews:AllViews}
|
||||
@RESTHEADER{GET /_api/view, List all Views, getViews:AllViews}
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Returns an object containing an array of all view descriptions.
|
||||
Returns an object containing a listing of all Views in a database, regardless
|
||||
of their type. It is an array of objects with the following attributes:
|
||||
- *id*
|
||||
- *name*
|
||||
- *type*
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
@RESTRETURNCODE{200}
|
||||
The list of views
|
||||
The list of Views
|
||||
|
||||
@EXAMPLES
|
||||
|
||||
Return information about all views:
|
||||
Return information about all Views:
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewGetAllViews}
|
||||
var url = "/_api/view";
|
||||
|
|
|
|||
|
|
@ -1,45 +0,0 @@
|
|||
@startDocuBlock patch_api_view_properties
|
||||
@brief partially changes properties of an ArangoDB view
|
||||
|
||||
@RESTHEADER{PATCH /_api/view/{view-name}/properties#arangosearch, Partially changes properties of an ArangoDB view, modifyView:partially}
|
||||
|
||||
@RESTURLPARAMETERS
|
||||
|
||||
@RESTURLPARAM{view-name,string,required}
|
||||
The name of the view.
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Changes the properties of a view.
|
||||
|
||||
On success an object with the following attributes is returned:
|
||||
- *id*: The identifier of the view
|
||||
- *name*: The name of the view
|
||||
- *type*: The view type
|
||||
- any additional view implementation specific properties
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
@RESTRETURNCODE{400}
|
||||
If the *view-name* is missing, then a *HTTP 400* is returned.
|
||||
|
||||
@RESTRETURNCODE{404}
|
||||
If the *view-name* is unknown, then a *HTTP 404* is returned.
|
||||
|
||||
@EXAMPLES
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewPatchProperties}
|
||||
var viewName = "products";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
var view = db._createView(viewName, viewType);
|
||||
var url = "/_api/view/" + view.name() + "/properties";
|
||||
|
||||
var response = logCurlRequest('PATCH', url, { });
|
||||
|
||||
assert(response.code === 200);
|
||||
|
||||
logJsonResponse(response);
|
||||
db._dropView(viewName);
|
||||
@END_EXAMPLE_ARANGOSH_RUN
|
||||
@endDocuBlock
|
||||
|
||||
|
|
@ -1,20 +1,22 @@
|
|||
@startDocuBlock patch_api_view_properties_iresearch
|
||||
@brief partially changes properties of an ArangoSearch view
|
||||
@startDocuBlock patch_api_view_properties_arangosearch
|
||||
@brief partially changes properties of an ArangoSearch View
|
||||
|
||||
@RESTHEADER{PATCH /_api/view/{view-name}/properties#ArangoSearch, Partially changes properties of an ArangoSearch view, modifyView}
|
||||
@RESTHEADER{PATCH /_api/view/{view-name}/properties#ArangoSearch, Partially changes properties of an ArangoSearch View, modifyView}
|
||||
|
||||
@RESTURLPARAMETERS
|
||||
|
||||
@RESTURLPARAM{view-name,string,required}
|
||||
The name of the view.
|
||||
The name of the View.
|
||||
|
||||
@RESTBODYPARAM{properties,object,optional,post_api_view_props}
|
||||
The view properties. If specified, then *properties* should be a JSON object
|
||||
containing the following attributes:
|
||||
@RESTBODYPARAM{links,object,optional,}
|
||||
Expects an object with the attribute keys being names of to be linked collections,
|
||||
and the link properties as attribute values. See
|
||||
[ArangoSearch View Link Properties](https://www.arangodb.com/docs/stable/arangosearch-views.html#link-properties)
|
||||
for details.
|
||||
|
||||
@RESTSTRUCT{cleanupIntervalStep,post_api_view_props,integer,optional,int64}
|
||||
@RESTBODYPARAM{cleanupIntervalStep,integer,optional,int64}
|
||||
Wait at least this many commits between removing unused files in the
|
||||
ArangoSearch data directory (default: 10, to disable use: 0).
|
||||
ArangoSearch data directory (default: 2, to disable use: 0).
|
||||
For the case where the consolidation policies merge segments often (i.e. a lot
|
||||
of commit+consolidate), a lower value will cause a lot of disk space to be
|
||||
wasted.
|
||||
|
|
@ -22,15 +24,15 @@ For the case where the consolidation policies rarely merge segments (i.e. few
|
|||
inserts/deletes), a higher value will impact performance without any added
|
||||
benefits.<br/>
|
||||
_Background:_
|
||||
With every "commit" or "consolidate" operation a new state of the view
|
||||
With every "commit" or "consolidate" operation a new state of the View
|
||||
internal data-structures is created on disk.
|
||||
Old states/snapshots are released once there are no longer any users
|
||||
remaining.
|
||||
However, the files for the released states/snapshots are left on disk, and
|
||||
only removed by "cleanup" operation.
|
||||
|
||||
@RESTSTRUCT{commitIntervalMsec,post_api_view_props,integer,optional,int64}
|
||||
Wait at least this many milliseconds between committing view data store
|
||||
@RESTBODYPARAM{commitIntervalMsec,integer,optional,int64}
|
||||
Wait at least this many milliseconds between committing View data store
|
||||
changes and making documents visible to queries (default: 1000, to disable
|
||||
use: 0).
|
||||
For the case where there are a lot of inserts/updates, a lower value, until
|
||||
|
|
@ -40,10 +42,10 @@ For the case where there are a few inserts/updates, a higher value will impact
|
|||
performance and waste disk space for each commit call without any added
|
||||
benefits.<br/>
|
||||
_Background:_
|
||||
For data retrieval ArangoSearch views follow the concept of
|
||||
For data retrieval ArangoSearch Views follow the concept of
|
||||
"eventually-consistent", i.e. eventually all the data in ArangoDB will be
|
||||
matched by corresponding query expressions.
|
||||
The concept of ArangoSearch view "commit" operation is introduced to
|
||||
The concept of ArangoSearch View "commit" operation is introduced to
|
||||
control the upper-bound on the time until document addition/removals are
|
||||
actually reflected by corresponding query expressions.
|
||||
Once a "commit" operation is complete all documents added/removed prior to
|
||||
|
|
@ -51,25 +53,23 @@ _Background:_
|
|||
subsequent ArangoDB transactions, in-progress ArangoDB transactions will
|
||||
still continue to return a repeatable-read state.
|
||||
|
||||
|
||||
@RESTSTRUCT{consolidationIntervalMsec,post_api_view_props,integer,optional,int64}
|
||||
@RESTBODYPARAM{consolidationIntervalMsec,integer,optional,int64}
|
||||
Wait at least this many milliseconds between applying 'consolidationPolicy' to
|
||||
consolidate view data store and possibly release space on the filesystem
|
||||
(default: 60000, to disable use: 0).
|
||||
consolidate View data store and possibly release space on the filesystem
|
||||
(default: 10000, to disable use: 0).
|
||||
For the case where there are a lot of data modification operations, a higher
|
||||
value could potentially have the data store consume more space and file handles.
|
||||
For the case where there are a few data modification operations, a lower value
|
||||
will impact performance due to no segment candidates available for
|
||||
consolidation.<br/>
|
||||
_Background:_
|
||||
For data modification ArangoSearch views follow the concept of a
|
||||
For data modification ArangoSearch Views follow the concept of a
|
||||
"versioned data store". Thus old versions of data may be removed once there
|
||||
are no longer any users of the old data. The frequency of the cleanup and
|
||||
compaction operations are governed by 'consolidationIntervalMsec' and the
|
||||
candidates for compaction are selected via 'consolidationPolicy'.
|
||||
|
||||
|
||||
@RESTSTRUCT{consolidationPolicy,post_api_view_props,object,optional,post_api_view_props_consolidation}
|
||||
@RESTBODYPARAM{consolidationPolicy,object,optional,}
|
||||
The consolidation policy to apply for selecting which segments should be merged
|
||||
(default: {})<br/>
|
||||
_Background:_
|
||||
|
|
@ -82,69 +82,40 @@ _Background:_
|
|||
A "consolidation" operation selects one or more segments and copies all of
|
||||
their valid documents into a single new segment, thereby allowing the
|
||||
search algorithm to perform more optimally and for extra file handles to be
|
||||
released once old segments are no longer used.
|
||||
|
||||
|
||||
@RESTSTRUCT{type,post_api_view_props_consolidation,string,optional,string}
|
||||
The segment candidates for the "consolidation" operation are selected based
|
||||
upon several possible configurable formulas as defined by their types.
|
||||
The currently supported types are (default: "bytes_accum"):
|
||||
- *bytes_accum*: consolidate if and only if (`{threshold}` range `[0.0, 1.0]`):
|
||||
`{threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes`
|
||||
i.e. the sum of all candidate segment byte size is less than the total
|
||||
segment byte size multiplied by the `{threshold}`
|
||||
- *tier*: consolidate based on segment byte size and live document count
|
||||
as dictated by the customization attributes.
|
||||
|
||||
|
||||
@RESTSTRUCT{links,post_api_view_props,object,optional,post_api_view_links}
|
||||
The set of collection names associated with the properties.
|
||||
|
||||
|
||||
@RESTSTRUCT{[collection-name],post_api_view_links,object,optional,post_api_view_link_props}
|
||||
The link properties. If specified, then *properties* should be a JSON object
|
||||
containing the following attributes:
|
||||
|
||||
@RESTSTRUCT{analyzers,post_api_view_link_props,array,optional,string}
|
||||
The list of analyzers to be used for indexing of string values
|
||||
(default: ["identity"]).
|
||||
|
||||
|
||||
@RESTSTRUCT{fields,post_api_view_link_props,object,optional,post_api_view_fields}
|
||||
The field properties. If specified, then *properties* should be a JSON object
|
||||
containing the following attributes:
|
||||
|
||||
@RESTSTRUCT{field-name,post_api_view_fields,array,optional,object}
|
||||
This is a recursive structure for the specific attribute path, potentially
|
||||
containing any of the following attributes:
|
||||
*analyzers*, *includeAllFields*, *trackListPositions*, *storeValues*
|
||||
Any attributes not specified are inherited from the parent.
|
||||
|
||||
|
||||
@RESTSTRUCT{includeAllFields,post_api_view_link_props,boolean,optional,bool}
|
||||
The flag determines whether or not to index all fields on a particular level of
|
||||
depth (default: false).
|
||||
|
||||
@RESTSTRUCT{trackListPositions,post_api_view_link_props,boolean,optional,bool}
|
||||
The flag determines whether or not values in a lists should be treated separate
|
||||
(default: false).
|
||||
|
||||
@RESTSTRUCT{storeValues,post_api_view_link_props,string,optional,string}
|
||||
How should the view track the attribute values, this setting allows for
|
||||
additional value retrieval optimizations, one of:
|
||||
- *none*: Do not store values by the view
|
||||
- *id*: Store only information about value presence, to allow use of the EXISTS() function
|
||||
(default "none").
|
||||
|
||||
released once old segments are no longer used.<br/>
|
||||
Sub-properties:
|
||||
- `type` (string, _optional_):
|
||||
The segment candidates for the "consolidation" operation are selected based
|
||||
upon several possible configurable formulas as defined by their types.
|
||||
The currently supported types are:
|
||||
- `"tier"` (default): consolidate based on segment byte size and live
|
||||
document count as dictated by the customization attributes. If this type
|
||||
is used, then below `segments*` and `minScore` properties are available.
|
||||
- `"bytes_accum"`: consolidate if and only if
|
||||
`{threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes`
|
||||
i.e. the sum of all candidate segment byte size is less than the total
|
||||
segment byte size multiplied by the `{threshold}`. If this type is used,
|
||||
then below `threshold` property is available.
|
||||
- `threshold` (number, _optional_): value in the range `[0.0, 1.0]`
|
||||
- `segmentsBytesFloor` (number, _optional_): Defines the value (in bytes) to
|
||||
treat all smaller segments as equal for consolidation selection
|
||||
(default: 2097152)
|
||||
- `segmentsBytesMax` (number, _optional_): Maximum allowed size of all
|
||||
consolidated segments in bytes (default: 5368709120)
|
||||
- `segmentsMax` (number, _optional_): The maximum number of segments that will
|
||||
be evaluated as candidates for consolidation (default: 10)
|
||||
- `segmentsMin` (number, _optional_): The minimum number of segments that will
|
||||
be evaluated as candidates for consolidation (default: 1)
|
||||
- `minScore` (number, _optional_): (default: 0)
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Changes the properties of a view.
|
||||
Changes the properties of a View by updating the specified attributes.
|
||||
|
||||
On success an object with the following attributes is returned:
|
||||
- *id*: The identifier of the view
|
||||
- *name*: The name of the view
|
||||
- *type*: The view type
|
||||
- all additional arangosearch view implementation specific properties
|
||||
- *id*: The identifier of the View
|
||||
- *name*: The name of the View
|
||||
- *type*: The View type
|
||||
- all additional ArangoSearch View implementation specific properties
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
|
|
@ -156,7 +127,7 @@ If the *view-name* is unknown, then a *HTTP 404* is returned.
|
|||
|
||||
@EXAMPLES
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestIResearchViewPatchProperties}
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewPatchPropertiesArangoSearch}
|
||||
var viewName = "products";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
@startDocuBlock post_api_view
|
||||
@brief creates an ArangoDB view
|
||||
|
||||
@RESTHEADER{POST /_api/view#arangosearch, Create an ArangoDB view, createView:Create}
|
||||
|
||||
@RESTBODYPARAM{name,string,required,string}
|
||||
The name of the view.
|
||||
|
||||
@RESTBODYPARAM{type,string,required,string}
|
||||
The type of the view. must be equal to one of the supported ArangoDB view
|
||||
types.
|
||||
|
||||
@RESTBODYPARAM{properties,object,optional,post_api_view_props}
|
||||
The view properties. If specified, then *properties* should be a JSON object
|
||||
containing the attributes supported by the specific view type.
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Creates a new view with a given name and properties if it does not already
|
||||
exist.
|
||||
|
||||
**Note**: view can't be created with the links. Please use PUT/PATCH
|
||||
for links management.
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
@RESTRETURNCODE{400}
|
||||
If the *view-name* is missing, then a *HTTP 400* is
|
||||
returned.
|
||||
|
||||
@RESTRETURNCODE{404}
|
||||
If the *view-name* is unknown, then a *HTTP 404* is returned.
|
||||
|
||||
@EXAMPLES
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestIResearchViewPostView}
|
||||
var url = "/_api/view";
|
||||
var body = {
|
||||
name: "testViewBasics",
|
||||
type: "arangosearch"
|
||||
};
|
||||
|
||||
var response = logCurlRequest('POST', url, body);
|
||||
|
||||
assert(response.code === 201);
|
||||
|
||||
logJsonResponse(response);
|
||||
|
||||
db._flushCache();
|
||||
db._dropView("testViewBasics");
|
||||
@END_EXAMPLE_ARANGOSH_RUN
|
||||
@endDocuBlock
|
||||
|
|
@ -0,0 +1,172 @@
|
|||
@startDocuBlock post_api_view_arangosearch
|
||||
@brief creates an ArangoSearch View
|
||||
|
||||
@RESTHEADER{POST /_api/view#arangosearch, Create an ArangoSearch View, createView}
|
||||
|
||||
@RESTBODYPARAM{name,string,required,string}
|
||||
The name of the View.
|
||||
|
||||
@RESTBODYPARAM{type,string,required,string}
|
||||
The type of the View. Must be equal to *"arangosearch"*.
|
||||
This option is immutable.
|
||||
|
||||
@RESTBODYPARAM{links,object,optional,}
|
||||
Expects an object with the attribute keys being names of to be linked collections,
|
||||
and the link properties as attribute values. See
|
||||
[ArangoSearch View Link Properties](https://www.arangodb.com/docs/stable/arangosearch-views.html#link-properties)
|
||||
for details.
|
||||
|
||||
@RESTBODYPARAM{primarySort,array,optional,object}
|
||||
A primary sort order can be defined to enable an AQL optimization. If a query
|
||||
iterates over all documents of a View, wants to sort them by attribute values
|
||||
and the (left-most) fields to sort by as well as their sorting direction match
|
||||
with the *primarySort* definition, then the `SORT` operation is optimized away.
|
||||
This option is immutable.
|
||||
|
||||
Expects an array of objects, each specifying a field (attribute path) and a
|
||||
sort direction (`"asc` for ascending, `"desc"` for descending):
|
||||
`[ { "field": "attr", "direction": "asc"}, … ]`
|
||||
|
||||
@RESTBODYPARAM{cleanupIntervalStep,integer,optional,int64}
|
||||
Wait at least this many commits between removing unused files in the
|
||||
ArangoSearch data directory (default: 2, to disable use: 0).
|
||||
For the case where the consolidation policies merge segments often (i.e. a lot
|
||||
of commit+consolidate), a lower value will cause a lot of disk space to be
|
||||
wasted.
|
||||
For the case where the consolidation policies rarely merge segments (i.e. few
|
||||
inserts/deletes), a higher value will impact performance without any added
|
||||
benefits.<br/>
|
||||
_Background:_
|
||||
With every "commit" or "consolidate" operation a new state of the View
|
||||
internal data-structures is created on disk.
|
||||
Old states/snapshots are released once there are no longer any users
|
||||
remaining.
|
||||
However, the files for the released states/snapshots are left on disk, and
|
||||
only removed by "cleanup" operation.
|
||||
|
||||
@RESTBODYPARAM{commitIntervalMsec,integer,optional,int64}
|
||||
Wait at least this many milliseconds between committing View data store
|
||||
changes and making documents visible to queries (default: 1000, to disable
|
||||
use: 0).
|
||||
For the case where there are a lot of inserts/updates, a lower value, until
|
||||
commit, will cause the index not to account for them and memory usage would
|
||||
continue to grow.
|
||||
For the case where there are a few inserts/updates, a higher value will impact
|
||||
performance and waste disk space for each commit call without any added
|
||||
benefits.<br/>
|
||||
_Background:_
|
||||
For data retrieval ArangoSearch Views follow the concept of
|
||||
"eventually-consistent", i.e. eventually all the data in ArangoDB will be
|
||||
matched by corresponding query expressions.
|
||||
The concept of ArangoSearch View "commit" operation is introduced to
|
||||
control the upper-bound on the time until document addition/removals are
|
||||
actually reflected by corresponding query expressions.
|
||||
Once a "commit" operation is complete all documents added/removed prior to
|
||||
the start of the "commit" operation will be reflected by queries invoked in
|
||||
subsequent ArangoDB transactions, in-progress ArangoDB transactions will
|
||||
still continue to return a repeatable-read state.
|
||||
|
||||
@RESTBODYPARAM{consolidationIntervalMsec,integer,optional,int64}
|
||||
Wait at least this many milliseconds between applying 'consolidationPolicy' to
|
||||
consolidate View data store and possibly release space on the filesystem
|
||||
(default: 10000, to disable use: 0).
|
||||
For the case where there are a lot of data modification operations, a higher
|
||||
value could potentially have the data store consume more space and file handles.
|
||||
For the case where there are a few data modification operations, a lower value
|
||||
will impact performance due to no segment candidates available for
|
||||
consolidation.<br/>
|
||||
_Background:_
|
||||
For data modification ArangoSearch Views follow the concept of a
|
||||
"versioned data store". Thus old versions of data may be removed once there
|
||||
are no longer any users of the old data. The frequency of the cleanup and
|
||||
compaction operations are governed by 'consolidationIntervalMsec' and the
|
||||
candidates for compaction are selected via 'consolidationPolicy'.
|
||||
|
||||
@RESTBODYPARAM{consolidationPolicy,object,optional,}
|
||||
The consolidation policy to apply for selecting which segments should be merged
|
||||
(default: {})<br/>
|
||||
_Background:_
|
||||
With each ArangoDB transaction that inserts documents one or more
|
||||
ArangoSearch internal segments gets created.
|
||||
Similarly for removed documents the segments that contain such documents
|
||||
will have these documents marked as 'deleted'.
|
||||
Over time this approach causes a lot of small and sparse segments to be
|
||||
created.
|
||||
A "consolidation" operation selects one or more segments and copies all of
|
||||
their valid documents into a single new segment, thereby allowing the
|
||||
search algorithm to perform more optimally and for extra file handles to be
|
||||
released once old segments are no longer used.<br/>
|
||||
Sub-properties:
|
||||
- `type` (string, _optional_):
|
||||
The segment candidates for the "consolidation" operation are selected based
|
||||
upon several possible configurable formulas as defined by their types.
|
||||
The currently supported types are:
|
||||
- `"tier"` (default): consolidate based on segment byte size and live
|
||||
document count as dictated by the customization attributes. If this type
|
||||
is used, then below `segments*` and `minScore` properties are available.
|
||||
- `"bytes_accum"`: consolidate if and only if
|
||||
`{threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes`
|
||||
i.e. the sum of all candidate segment byte size is less than the total
|
||||
segment byte size multiplied by the `{threshold}`. If this type is used,
|
||||
then below `threshold` property is available.
|
||||
- `threshold` (number, _optional_): value in the range `[0.0, 1.0]`
|
||||
- `segmentsBytesFloor` (number, _optional_): Defines the value (in bytes) to
|
||||
treat all smaller segments as equal for consolidation selection
|
||||
(default: 2097152)
|
||||
- `segmentsBytesMax` (number, _optional_): Maximum allowed size of all
|
||||
consolidated segments in bytes (default: 5368709120)
|
||||
- `segmentsMax` (number, _optional_): The maximum number of segments that will
|
||||
be evaluated as candidates for consolidation (default: 10)
|
||||
- `segmentsMin` (number, _optional_): The minimum number of segments that will
|
||||
be evaluated as candidates for consolidation (default: 1)
|
||||
- `minScore` (number, _optional_): (default: 0)
|
||||
|
||||
@RESTBODYPARAM{writebufferIdle,integer,optional,int64}
|
||||
Maximum number of writers (segments) cached in the pool
|
||||
(default: 64, use 0 to disable, immutable)
|
||||
|
||||
@RESTBODYPARAM{writebufferActive,integer,optional,int64}
|
||||
Maximum number of concurrent active writers (segments) that perform a
|
||||
transaction. Other writers (segments) wait till current active writers
|
||||
(segments) finish (default: 0, use 0 to disable, immutable)
|
||||
|
||||
@RESTBODYPARAM{writebufferSizeMax,integer,optional,int64}
|
||||
Maximum memory byte size per writer (segment) before a writer (segment) flush
|
||||
is triggered. `0` value turns off this limit for any writer (buffer) and data
|
||||
will be flushed periodically based on the value defined for the flush thread
|
||||
(ArangoDB server startup option). `0` value should be used carefully due to
|
||||
high potential memory consumption
|
||||
(default: 33554432, use 0 to disable, immutable)
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Creates a new View with a given name and properties if it does not
|
||||
already exist.
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
@RESTRETURNCODE{400}
|
||||
If the *name* or *type* attribute are missing or invalid, then an *HTTP 400*
|
||||
error is returned.
|
||||
|
||||
@RESTRETURNCODE{409}
|
||||
If a View called *name* already exists, then an *HTTP 409* error is returned.
|
||||
|
||||
@EXAMPLES
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewPostViewArangoSearch}
|
||||
var url = "/_api/view";
|
||||
var body = {
|
||||
name: "testViewBasics",
|
||||
type: "arangosearch"
|
||||
};
|
||||
|
||||
var response = logCurlRequest('POST', url, body);
|
||||
|
||||
assert(response.code === 201);
|
||||
|
||||
logJsonResponse(response);
|
||||
|
||||
db._flushCache();
|
||||
db._dropView("testViewBasics");
|
||||
@END_EXAMPLE_ARANGOSH_RUN
|
||||
@endDocuBlock
|
||||
|
|
@ -1,173 +0,0 @@
|
|||
@startDocuBlock post_api_view_iresearch
|
||||
@brief creates an ArangoSearch view
|
||||
|
||||
@RESTHEADER{POST /_api/view#ArangoSearch, Create an ArangoSearch view, createView}
|
||||
|
||||
@RESTBODYPARAM{name,string,required,string}
|
||||
The name of the view.
|
||||
|
||||
@RESTBODYPARAM{type,string,required,string}
|
||||
The type of the view. must be equal to *"arangosearch"*
|
||||
|
||||
@RESTBODYPARAM{properties,object,optional,post_api_view_props}
|
||||
The view properties. If specified, then *properties* should be a JSON object
|
||||
containing the following attributes:
|
||||
|
||||
@RESTSTRUCT{cleanupIntervalStep,post_api_view_props,integer,optional,int64}
|
||||
Wait at least this many commits between removing unused files in the
|
||||
ArangoSearch data directory (default: 10, to disable use: 0).
|
||||
For the case where the consolidation policies merge segments often (i.e. a lot
|
||||
of commit+consolidate), a lower value will cause a lot of disk space to be
|
||||
wasted.
|
||||
For the case where the consolidation policies rarely merge segments (i.e. few
|
||||
inserts/deletes), a higher value will impact performance without any added
|
||||
benefits.<br/>
|
||||
_Background:_
|
||||
With every "commit" or "consolidate" operation a new state of the view
|
||||
internal data-structures is created on disk.
|
||||
Old states/snapshots are released once there are no longer any users
|
||||
remaining.
|
||||
However, the files for the released states/snapshots are left on disk, and
|
||||
only removed by "cleanup" operation.
|
||||
|
||||
@RESTSTRUCT{commitIntervalMsec,post_api_view_props,integer,optional,int64}
|
||||
Wait at least this many milliseconds between committing view data store
|
||||
changes and making documents visible to queries (default: 1000, to disable
|
||||
use: 0).
|
||||
For the case where there are a lot of inserts/updates, a lower value, until
|
||||
commit, will cause the index not to account for them and memory usage would
|
||||
continue to grow.
|
||||
For the case where there are a few inserts/updates, a higher value will impact
|
||||
performance and waste disk space for each commit call without any added
|
||||
benefits.<br/>
|
||||
_Background:_
|
||||
For data retrieval ArangoSearch views follow the concept of
|
||||
"eventually-consistent", i.e. eventually all the data in ArangoDB will be
|
||||
matched by corresponding query expressions.
|
||||
The concept of ArangoSearch view "commit" operation is introduced to
|
||||
control the upper-bound on the time until document addition/removals are
|
||||
actually reflected by corresponding query expressions.
|
||||
Once a "commit" operation is complete all documents added/removed prior to
|
||||
the start of the "commit" operation will be reflected by queries invoked in
|
||||
subsequent ArangoDB transactions, in-progress ArangoDB transactions will
|
||||
still continue to return a repeatable-read state.
|
||||
|
||||
|
||||
@RESTSTRUCT{consolidationIntervalMsec,post_api_view_props,integer,optional,int64}
|
||||
Wait at least this many milliseconds between applying 'consolidationPolicy' to
|
||||
consolidate view data store and possibly release space on the filesystem
|
||||
(default: 60000, to disable use: 0).
|
||||
For the case where there are a lot of data modification operations, a higher
|
||||
value could potentially have the data store consume more space and file handles.
|
||||
For the case where there are a few data modification operations, a lower value
|
||||
will impact performance due to no segment candidates available for
|
||||
consolidation.<br/>
|
||||
_Background:_
|
||||
For data modification ArangoSearch views follow the concept of a
|
||||
"versioned data store". Thus old versions of data may be removed once there
|
||||
are no longer any users of the old data. The frequency of the cleanup and
|
||||
compaction operations are governed by 'consolidationIntervalMsec' and the
|
||||
candidates for compaction are selected via 'consolidationPolicy'.
|
||||
|
||||
|
||||
@RESTSTRUCT{consolidationPolicy,post_api_view_props,object,optional,post_api_view_props_consolidation}
|
||||
The consolidation policy to apply for selecting which segments should be merged
|
||||
(default: {})<br/>
|
||||
_Background:_
|
||||
With each ArangoDB transaction that inserts documents one or more
|
||||
ArangoSearch internal segments gets created.
|
||||
Similarly for removed documents the segments that contain such documents
|
||||
will have these documents marked as 'deleted'.
|
||||
Over time this approach causes a lot of small and sparse segments to be
|
||||
created.
|
||||
A "consolidation" operation selects one or more segments and copies all of
|
||||
their valid documents into a single new segment, thereby allowing the
|
||||
search algorithm to perform more optimally and for extra file handles to be
|
||||
released once old segments are no longer used.
|
||||
|
||||
|
||||
@RESTSTRUCT{type,post_api_view_props_consolidation,string,optional,string}
|
||||
The segment candidates for the "consolidation" operation are selected based
|
||||
upon several possible configurable formulas as defined by their types.
|
||||
The currently supported types are (default: "bytes_accum"):
|
||||
- *bytes_accum*: consolidate if and only if (`{threshold}` range `[0.0, 1.0]`):
|
||||
`{threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes`
|
||||
i.e. the sum of all candidate segment byte size is less than the total
|
||||
segment byte size multiplied by the `{threshold}`
|
||||
- *tier*: consolidate based on segment byte size and live document count
|
||||
as dictated by the customization attributes.
|
||||
|
||||
|
||||
@RESTSTRUCT{links,post_api_view_props,object,optional,post_api_view_links}
|
||||
The set of collection names associated with the properties.
|
||||
|
||||
@RESTSTRUCT{[collection-name],post_api_view_links,object,optional,post_api_view_link_props}
|
||||
The link properties. If specified, then *properties* should be a JSON object
|
||||
containing the following attributes:
|
||||
|
||||
@RESTSTRUCT{analyzers,post_api_view_link_props,array,optional,string}
|
||||
The list of analyzers to be used for indexing of string values
|
||||
(default: ["identity"]).
|
||||
|
||||
|
||||
@RESTSTRUCT{fields,post_api_view_link_props,object,optional,post_api_view_fields}
|
||||
The field properties. If specified, then *properties* should be a JSON object
|
||||
containing the following attributes:
|
||||
|
||||
@RESTSTRUCT{field-name,post_api_view_fields,array,optional,object}
|
||||
This is a recursive structure for the specific attribute path, potentially
|
||||
containing any of the following attributes:
|
||||
*analyzers*, *includeAllFields*, *trackListPositions*, *storeValues*
|
||||
Any attributes not specified are inherited from the parent.
|
||||
|
||||
|
||||
@RESTSTRUCT{includeAllFields,post_api_view_link_props,boolean,optional,bool}
|
||||
The flag determines whether or not to index all fields on a particular level of
|
||||
depth (default: false).
|
||||
|
||||
@RESTSTRUCT{trackListPositions,post_api_view_link_props,boolean,optional,bool}
|
||||
The flag determines whether or not values in a lists should be treated separate
|
||||
(default: false).
|
||||
|
||||
@RESTSTRUCT{storeValues,post_api_view_link_props,string,optional,string}
|
||||
How should the view track the attribute values, this setting allows for
|
||||
additional value retrieval optimizations, one of:
|
||||
- *none*: Do not store values by the view
|
||||
- *id*: Store only information about value presence, to allow use of the EXISTS() function
|
||||
(default "none").
|
||||
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Creates a new view with a given name and properties if it does not
|
||||
already exist.
|
||||
|
||||
**Note**: view can't be created with the links. Please use PUT/PATCH for links
|
||||
management.
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
@RESTRETURNCODE{400}
|
||||
If the *view-name* is missing, then a *HTTP 400* is returned.
|
||||
|
||||
@RESTRETURNCODE{404}
|
||||
If the *view-name* is unknown, then a *HTTP 404* is returned.
|
||||
|
||||
@EXAMPLES
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewPostView}
|
||||
var url = "/_api/view";
|
||||
var body = {
|
||||
name: "testViewBasics",
|
||||
type: "arangosearch"
|
||||
};
|
||||
|
||||
var response = logCurlRequest('POST', url, body);
|
||||
|
||||
assert(response.code === 201);
|
||||
|
||||
logJsonResponse(response);
|
||||
|
||||
db._flushCache();
|
||||
db._dropView("testViewBasics");
|
||||
@END_EXAMPLE_ARANGOSH_RUN
|
||||
@endDocuBlock
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
@startDocuBlock put_api_view_properties
|
||||
@brief changes properties of an ArangoDB view
|
||||
|
||||
@RESTHEADER{PUT /_api/view/{view-name}/properties#arangosearch, Change properties of an ArangoDB view, modifyView:One}
|
||||
|
||||
@RESTURLPARAMETERS
|
||||
|
||||
@RESTURLPARAM{view-name,string,required}
|
||||
The name of the view.
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Changes the properties of a view.
|
||||
|
||||
On success an object with the following attributes is returned:
|
||||
- *id*: The identifier of the view
|
||||
- *name*: The name of the view
|
||||
- *type*: The view type
|
||||
- any additional view implementation specific properties
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
@RESTRETURNCODE{400}
|
||||
If the *view-name* is missing, then a *HTTP 400* is returned.
|
||||
|
||||
@RESTRETURNCODE{404}
|
||||
If the *view-name* is unknown, then a *HTTP 404* is returned.
|
||||
|
||||
@EXAMPLES
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewPutProperties}
|
||||
var viewName = "products";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
var view = db._createView(viewName, viewType);
|
||||
var url = "/_api/view/" + view.name() + "/properties";
|
||||
|
||||
var response = logCurlRequest('PUT', url, { });
|
||||
|
||||
assert(response.code === 200);
|
||||
|
||||
logJsonResponse(response);
|
||||
db._dropView(viewName);
|
||||
@END_EXAMPLE_ARANGOSH_RUN
|
||||
@endDocuBlock
|
||||
|
|
@ -1,20 +1,22 @@
|
|||
@startDocuBlock put_api_view_properties_iresearch
|
||||
@brief changes properties of an ArangoSearch view
|
||||
@startDocuBlock put_api_view_properties_arangosearch
|
||||
@brief changes all properties of an ArangoSearch View
|
||||
|
||||
@RESTHEADER{PUT /_api/view/{view-name}/properties#ArangoSearch, Change properties of an ArangoSearch view, modifyView}
|
||||
@RESTHEADER{PUT /_api/view/{view-name}/properties#ArangoSearch, Change properties of an ArangoSearch View, modifyView}
|
||||
|
||||
@RESTURLPARAMETERS
|
||||
|
||||
@RESTURLPARAM{view-name,string,required}
|
||||
The name of the view.
|
||||
The name of the View.
|
||||
|
||||
@RESTBODYPARAM{properties,object,optional,post_api_view_props}
|
||||
The view properties. If specified, then *properties* should be a JSON object
|
||||
containing the following attributes:
|
||||
@RESTBODYPARAM{links,object,optional,}
|
||||
Expects an object with the attribute keys being names of to be linked collections,
|
||||
and the link properties as attribute values. See
|
||||
[ArangoSearch View Link Properties](https://www.arangodb.com/docs/stable/arangosearch-views.html#link-properties)
|
||||
for details.
|
||||
|
||||
@RESTSTRUCT{cleanupIntervalStep,post_api_view_props,integer,optional,int64}
|
||||
@RESTBODYPARAM{cleanupIntervalStep,integer,optional,int64}
|
||||
Wait at least this many commits between removing unused files in the
|
||||
ArangoSearch data directory (default: 10, to disable use: 0).
|
||||
ArangoSearch data directory (default: 2, to disable use: 0).
|
||||
For the case where the consolidation policies merge segments often (i.e. a lot
|
||||
of commit+consolidate), a lower value will cause a lot of disk space to be
|
||||
wasted.
|
||||
|
|
@ -22,15 +24,15 @@ For the case where the consolidation policies rarely merge segments (i.e. few
|
|||
inserts/deletes), a higher value will impact performance without any added
|
||||
benefits.<br/>
|
||||
_Background:_
|
||||
With every "commit" or "consolidate" operation a new state of the view
|
||||
With every "commit" or "consolidate" operation a new state of the View
|
||||
internal data-structures is created on disk.
|
||||
Old states/snapshots are released once there are no longer any users
|
||||
remaining.
|
||||
However, the files for the released states/snapshots are left on disk, and
|
||||
only removed by "cleanup" operation.
|
||||
|
||||
@RESTSTRUCT{commitIntervalMsec,post_api_view_props,integer,optional,int64}
|
||||
Wait at least this many milliseconds between committing view data store
|
||||
@RESTBODYPARAM{commitIntervalMsec,integer,optional,int64}
|
||||
Wait at least this many milliseconds between committing View data store
|
||||
changes and making documents visible to queries (default: 1000, to disable
|
||||
use: 0).
|
||||
For the case where there are a lot of inserts/updates, a lower value, until
|
||||
|
|
@ -40,10 +42,10 @@ For the case where there are a few inserts/updates, a higher value will impact
|
|||
performance and waste disk space for each commit call without any added
|
||||
benefits.<br/>
|
||||
_Background:_
|
||||
For data retrieval ArangoSearch views follow the concept of
|
||||
For data retrieval ArangoSearch Views follow the concept of
|
||||
"eventually-consistent", i.e. eventually all the data in ArangoDB will be
|
||||
matched by corresponding query expressions.
|
||||
The concept of ArangoSearch view "commit" operation is introduced to
|
||||
The concept of ArangoSearch View "commit" operation is introduced to
|
||||
control the upper-bound on the time until document addition/removals are
|
||||
actually reflected by corresponding query expressions.
|
||||
Once a "commit" operation is complete all documents added/removed prior to
|
||||
|
|
@ -51,25 +53,23 @@ _Background:_
|
|||
subsequent ArangoDB transactions, in-progress ArangoDB transactions will
|
||||
still continue to return a repeatable-read state.
|
||||
|
||||
|
||||
@RESTSTRUCT{consolidationIntervalMsec,post_api_view_props,integer,optional,int64}
|
||||
@RESTBODYPARAM{consolidationIntervalMsec,integer,optional,int64}
|
||||
Wait at least this many milliseconds between applying 'consolidationPolicy' to
|
||||
consolidate view data store and possibly release space on the filesystem
|
||||
(default: 60000, to disable use: 0).
|
||||
consolidate View data store and possibly release space on the filesystem
|
||||
(default: 10000, to disable use: 0).
|
||||
For the case where there are a lot of data modification operations, a higher
|
||||
value could potentially have the data store consume more space and file handles.
|
||||
For the case where there are a few data modification operations, a lower value
|
||||
will impact performance due to no segment candidates available for
|
||||
consolidation.<br/>
|
||||
_Background:_
|
||||
For data modification ArangoSearch views follow the concept of a
|
||||
For data modification ArangoSearch Views follow the concept of a
|
||||
"versioned data store". Thus old versions of data may be removed once there
|
||||
are no longer any users of the old data. The frequency of the cleanup and
|
||||
compaction operations are governed by 'consolidationIntervalMsec' and the
|
||||
candidates for compaction are selected via 'consolidationPolicy'.
|
||||
|
||||
|
||||
@RESTSTRUCT{consolidationPolicy,post_api_view_props,object,optional,post_api_view_props_consolidation}
|
||||
@RESTBODYPARAM{consolidationPolicy,object,optional,}
|
||||
The consolidation policy to apply for selecting which segments should be merged
|
||||
(default: {})<br/>
|
||||
_Background:_
|
||||
|
|
@ -82,69 +82,40 @@ _Background:_
|
|||
A "consolidation" operation selects one or more segments and copies all of
|
||||
their valid documents into a single new segment, thereby allowing the
|
||||
search algorithm to perform more optimally and for extra file handles to be
|
||||
released once old segments are no longer used.
|
||||
|
||||
|
||||
@RESTSTRUCT{type,post_api_view_props_consolidation,string,optional,string}
|
||||
The segment candidates for the "consolidation" operation are selected based
|
||||
upon several possible configurable formulas as defined by their types.
|
||||
The currently supported types are (default: "bytes_accum"):
|
||||
- *bytes_accum*: consolidate if and only if (`{threshold}` range `[0.0, 1.0]`):
|
||||
`{threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes`
|
||||
i.e. the sum of all candidate segment byte size is less than the total
|
||||
segment byte size multiplied by the `{threshold}`
|
||||
- *tier*: consolidate based on segment byte size and live document count
|
||||
as dictated by the customization attributes.
|
||||
|
||||
|
||||
@RESTSTRUCT{links,post_api_view_props,object,optional,post_api_view_links}
|
||||
The set of collection names associated with the properties.
|
||||
|
||||
|
||||
@RESTSTRUCT{[collection-name],post_api_view_links,object,optional,post_api_view_link_props}
|
||||
The link properties. If specified, then *properties* should be a JSON object
|
||||
containing the following attributes:
|
||||
|
||||
@RESTSTRUCT{analyzers,post_api_view_link_props,array,optional,string}
|
||||
The list of analyzers to be used for indexing of string values
|
||||
(default: ["identity"]).
|
||||
|
||||
|
||||
@RESTSTRUCT{fields,post_api_view_link_props,object,optional,post_api_view_fields}
|
||||
The field properties. If specified, then *properties* should be a JSON object
|
||||
containing the following attributes:
|
||||
|
||||
@RESTSTRUCT{field-name,post_api_view_fields,array,optional,object}
|
||||
This is a recursive structure for the specific attribute path, potentially
|
||||
containing any of the following attributes:
|
||||
*analyzers*, *includeAllFields*, *trackListPositions*, *storeValues*
|
||||
Any attributes not specified are inherited from the parent.
|
||||
|
||||
|
||||
@RESTSTRUCT{includeAllFields,post_api_view_link_props,boolean,optional,bool}
|
||||
The flag determines whether or not to index all fields on a particular level of
|
||||
depth (default: false).
|
||||
|
||||
@RESTSTRUCT{trackListPositions,post_api_view_link_props,boolean,optional,bool}
|
||||
The flag determines whether or not values in a lists should be treated separate
|
||||
(default: false).
|
||||
|
||||
@RESTSTRUCT{storeValues,post_api_view_link_props,string,optional,string}
|
||||
How should the view track the attribute values, this setting allows for
|
||||
additional value retrieval optimizations, one of:
|
||||
- *none*: Do not store values by the view
|
||||
- *id*: Store only information about value presence, to allow use of the EXISTS() function
|
||||
(default "none").
|
||||
|
||||
released once old segments are no longer used.<br/>
|
||||
Sub-properties:
|
||||
- `type` (string, _optional_):
|
||||
The segment candidates for the "consolidation" operation are selected based
|
||||
upon several possible configurable formulas as defined by their types.
|
||||
The currently supported types are:
|
||||
- `"tier"` (default): consolidate based on segment byte size and live
|
||||
document count as dictated by the customization attributes. If this type
|
||||
is used, then below `segments*` and `minScore` properties are available.
|
||||
- `"bytes_accum"`: consolidate if and only if
|
||||
`{threshold} > (segment_bytes + sum_of_merge_candidate_segment_bytes) / all_segment_bytes`
|
||||
i.e. the sum of all candidate segment byte size is less than the total
|
||||
segment byte size multiplied by the `{threshold}`. If this type is used,
|
||||
then below `threshold` property is available.
|
||||
- `threshold` (number, _optional_): value in the range `[0.0, 1.0]`
|
||||
- `segmentsBytesFloor` (number, _optional_): Defines the value (in bytes) to
|
||||
treat all smaller segments as equal for consolidation selection
|
||||
(default: 2097152)
|
||||
- `segmentsBytesMax` (number, _optional_): Maximum allowed size of all
|
||||
consolidated segments in bytes (default: 5368709120)
|
||||
- `segmentsMax` (number, _optional_): The maximum number of segments that will
|
||||
be evaluated as candidates for consolidation (default: 10)
|
||||
- `segmentsMin` (number, _optional_): The minimum number of segments that will
|
||||
be evaluated as candidates for consolidation (default: 1)
|
||||
- `minScore` (number, _optional_): (default: 0)
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Changes the properties of a view.
|
||||
Changes the properties of a View by replacing them.
|
||||
|
||||
On success an object with the following attributes is returned:
|
||||
- *id*: The identifier of the view
|
||||
- *name*: The name of the view
|
||||
- *type*: The view type
|
||||
- all additional arangosearch view implementation specific properties
|
||||
- *id*: The identifier of the View
|
||||
- *name*: The name of the View
|
||||
- *type*: The View type
|
||||
- all additional ArangoSearch View implementation specific properties
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
|
|
@ -156,7 +127,7 @@ If the *view-name* is unknown, then a *HTTP 404* is returned.
|
|||
|
||||
@EXAMPLES
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestIResearchViewPutProperties}
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewPutPropertiesArangoSearch}
|
||||
var viewName = "products";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
|
|
@ -1,23 +1,23 @@
|
|||
@startDocuBlock put_api_view_rename
|
||||
@brief renames a view
|
||||
@brief renames a View
|
||||
|
||||
@RESTHEADER{PUT /_api/view/{view-name}/rename, Rename a view, modifyView:rename}
|
||||
@RESTHEADER{PUT /_api/view/{view-name}/rename, Rename a View, modifyView:rename}
|
||||
|
||||
@RESTURLPARAMETERS
|
||||
|
||||
@RESTURLPARAM{view-name,string,required}
|
||||
The name of the view to rename.
|
||||
The name of the View to rename.
|
||||
|
||||
@RESTDESCRIPTION
|
||||
Renames a view. Expects an object with the attribute(s)
|
||||
Renames a View. Expects an object with the attribute(s)
|
||||
- *name*: The new name
|
||||
|
||||
It returns an object with the attributes
|
||||
- *id*: The identifier of the view.
|
||||
- *name*: The new name of the view.
|
||||
- *type*: The view type.
|
||||
- *id*: The identifier of the View.
|
||||
- *name*: The new name of the View.
|
||||
- *type*: The View type.
|
||||
|
||||
**Note**: this method is not available in a cluster.
|
||||
**Note**: This method is not available in a cluster.
|
||||
|
||||
@RESTRETURNCODES
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ If the *view-name* is unknown, then a *HTTP 404* is returned.
|
|||
|
||||
@EXAMPLES
|
||||
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewPutViewRename}
|
||||
@EXAMPLE_ARANGOSH_RUN{RestViewPutRename}
|
||||
var viewName = "products1";
|
||||
var viewType = "arangosearch";
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue