0ba532b16a
Next steps after DC2DC and Cluster doc improvements: - We refactor replication sections and make more intuitive separation between Master/Slave and the new Active Failover in 3.3 - We create corresponding sections for Master/Slave and Active Failover in the Administration and Deployment chapters, as well as in the Scalability chapter, where these "modes" are introduced - We touch and improve the "Architecture" chapter as well, where some architecture info have to be placed - We reorg the TOC having in more "logical" order: -- Deployment -- Administration -- Security -- Monitoring -- Troubleshooting - We adds parts in the TOC - We add toc per pages, using page-toc plugin - We also put close together "Scalability" and "Architecture" chapters, preliminary steps of further improvements / aggregation - We improve swagger Internal Ref: - https://github.com/arangodb/planning/issues/1692 - https://github.com/arangodb/planning/issues/1655 - https://github.com/arangodb/planning/issues/1858 - https://github.com/arangodb/planning/issues/973 (partial fix) - https://github.com/arangodb/planning/issues/1498 (partial fix) |
||
|---|---|---|
| .. | ||
| ArangoSearch.md | ||
| Creating.md | ||
| Getting.md | ||
| Modifying.md | ||
| README.md | ||
README.md
HTTP Interface for Views
Views
This is an introduction to ArangoDB's HTTP interface for views.
View
A view consists of documents. It is uniquely identified by its identifier. It also has a unique name that clients should use to identify and access it. View can be renamed. This will change the view name, but not the view identifier. Views have a type that is specified by the user when the view is created.
The only available view type currently is: "arangosearch".
ArangoSearch View
A natively integrated AQL extension that allows one to:
- evaluate together documents located in different collections
- filter documents based on AQL boolean expressions and functions
- sort the resultset based on how closely each document matched the filter
View Identifier
A view identifier lets you refer to a view in a database. It is a string value and is unique within the database. ArangoDB currently uses 64bit unsigned integer values to maintain view ids internally. When returning view ids to clients, ArangoDB will put them into a string to ensure the view id is not clipped by clients that do not support big integers. Clients should treat the view ids returned by ArangoDB as opaque strings when they store or use them locally.
View Name
A view name identifies a view in a database. It is a string and is unique within the database. Unlike the view identifier it is supplied by the creator of the view . The view name must consist of letters, digits, and the _ (underscore) and - (dash) characters only. Please refer to Naming Conventions in ArangoDB for more information on valid view names.
Address of a View
All views in ArangoDB have a unique identifier and a unique name. ArangoDB internally uses the view's unique identifier to look up the view. This identifier however is managed by ArangoDB and the user has no control over it. In order to allow users to use their own names, each view also has a unique name, which is specified by the user. To access a view from the user perspective, the view name should be used, i.e.:
http://server:port/_api/view/view-name
For example: Assume that the view identifier is 7254820 and the view name is demo, then the URL of that view is:
http://localhost:8529/_api/view/demo