diff --git a/Documentation/Books/Users/Aql/DataModification.mdpp b/Documentation/Books/Users/Aql/DataModification.mdpp index 600d56655f..1574239b39 100644 --- a/Documentation/Books/Users/Aql/DataModification.mdpp +++ b/Documentation/Books/Users/Aql/DataModification.mdpp @@ -43,7 +43,7 @@ matching documents in collection "users": The name of the modified collection ("backup" in the above cases) must be known to the AQL executor at query-compile time and cannot change at -runtime. Using a bind parameter to specify the collection name is allowed. +runtime. Using a bind parameter to specify the [collection name](../Glossary/README.html#collection_name) is allowed. On a single server, data-modification operations are executed transactionally. If a data-modification operation fails, it will be rolled back automatically diff --git a/Documentation/Books/Users/Aql/Functions.mdpp b/Documentation/Books/Users/Aql/Functions.mdpp index 615175a7c3..a6953107f1 100644 --- a/Documentation/Books/Users/Aql/Functions.mdpp +++ b/Documentation/Books/Users/Aql/Functions.mdpp @@ -587,9 +587,9 @@ AQL supports the following functions to operate on document values: RETURN KEEP(doc, 'firstname', 'name', 'likes') -- *PARSE_IDENTIFIER(document-handle)*: Parses the document handle specified in +- *PARSE_IDENTIFIER(document-handle)*: Parses the [document handle](../Glossary/README.html#document_handle) specified in *document-handle* and returns a the handle's individual parts a separate attributes. - This function can be used to easily determine the collection name and key from a given document. + This function can be used to easily determine the [collection name](../Glossary/README.html#collection_name) and key from a given document. The *document-handle* can either be a regular document from a collection, or a document identifier string (e.g. *_users/1234*). Passing either a non-string or a non-document or a document without an *_id* attribute will result in an error. @@ -608,7 +608,7 @@ AQL supports the following functions to operate on document values: !SUBSUBSECTION Geo functions -AQL offers the following functions to filter data based on geo indexes: +AQL offers the following functions to filter data based on [geo indexes](../Glossary/README.html#geo_index): - *NEAR(collection, latitude, longitude, limit, distancename)*: Returns at most *limit* documents from collection *collection* that are near @@ -637,7 +637,7 @@ with an error. !SUBSUBSECTION Fulltext functions -AQL offers the following functions to filter data based on fulltext indexes: +AQL offers the following functions to filter data based on [fulltext indexes](../Glossary/README.html#fulltext_index): - *FULLTEXT(collection, attribute, query)*: Returns all documents from collection *collection* for which the attribute *attribute* @@ -1092,7 +1092,7 @@ function categories: DOCUMENT([ "users/john", "users/amy" ]) - *SKIPLIST(collection, condition, skip, limit)*: Return all documents - from a skiplist index on collection *collection* that match the specified *condition*. + from a [skiplist index](../Glossary/README.html#skiplist_index) on collection *collection* that match the specified *condition*. This is a shortcut method to use a skiplist index for retrieving specific documents in indexed order. The skiplist index supports equality and less than/greater than queries. The *skip* and *limit* parameters are optional but can be specified to further limit the diff --git a/Documentation/Books/Users/Aql/Operations.mdpp b/Documentation/Books/Users/Aql/Operations.mdpp index acbd4ebce5..03a9fc5920 100644 --- a/Documentation/Books/Users/Aql/Operations.mdpp +++ b/Documentation/Books/Users/Aql/Operations.mdpp @@ -267,7 +267,7 @@ is not transactional. Only a single *REMOVE* statement is allowed per AQL query, and it cannot be combined with other data-modification or retrieval operations. A remove operation is -restricted to a single collection, and the collection name must not be dynamic. +restricted to a single collection, and the [collection name](../Glossary/README.html#collection_name) must not be dynamic. The syntax for a remove operation is: @@ -277,7 +277,7 @@ REMOVE key-expression IN collection options *collection* must contain the name of the collection to remove the documents from. *key-expression* must be an expression that contains the document identification. -This can either be a string (which must then contain the document key) or a +This can either be a string (which must then contain the [document key](../Glossary/README.html#document_key)) or a document, which must contain a *_key* attribute. The following queries are thus equivalent: @@ -542,7 +542,7 @@ FOR i IN 1..100 INSERT { value: i } IN numbers ``` -When inserting into an edge collection, it is mandatory to specify the attributes +When inserting into an [edge collection](../Glossary/README.html#edge_collection), it is mandatory to specify the attributes *_from* and *_to* in document: ``` diff --git a/Documentation/Books/Users/AqlExamples/CollectionQueries.mdpp b/Documentation/Books/Users/AqlExamples/CollectionQueries.mdpp index 942911a87f..eb0c8d19b3 100644 --- a/Documentation/Books/Users/AqlExamples/CollectionQueries.mdpp +++ b/Documentation/Books/Users/AqlExamples/CollectionQueries.mdpp @@ -86,7 +86,7 @@ relationships between users. The example data for *relations* are as follows: Note that all documents created in the two collections will automatically get the following server-generated attributes: -* *_id*: A unique id, consisting of collection name and a server-side sequence value +* *_id*: A unique id, consisting of [collection name](../Glossary/README.html#collection_name) and a server-side sequence value * *_key*: The server sequence value * *_rev*: The document's revision id @@ -97,6 +97,6 @@ Please also note that with real-world data, you might want to create additional indexes on the data (left out here for brevity). Adding indexes on attributes that are used in *FILTER* statements may considerably speed up queries. Furthermore, instead of using attributes such as *id*, *from* and *to*, you might want to use the built-in -*_id*, *_from* and *_to* attributes. Finally, edge collections provide a nice way of +*_id*, *_from* and *_to* attributes. Finally, [edge collection](../Glossary/README.html#edge_collection)s provide a nice way of establishing references / links between documents. These features have been left out here for brevity as well. diff --git a/Documentation/Books/Users/Arangodump/README.mdpp b/Documentation/Books/Users/Arangodump/README.mdpp index d87e8ecf2f..7832dabdc5 100644 --- a/Documentation/Books/Users/Arangodump/README.mdpp +++ b/Documentation/Books/Users/Arangodump/README.mdpp @@ -26,7 +26,7 @@ or use authentication, you can use the following command-line options: * *--server.disable-authentication *: whether or not to use authentication Here's an example of dumping data from a non-standard endpoint, using a dedicated -database name: +[database name](../Glossary/README.html#database_name): unix> arangodump --server.endpoint tcp://192.168.173.13:8531 --server.username backup --server.database mydb --output-directory "dump" diff --git a/Documentation/Books/Users/Arangoimp/README.mdpp b/Documentation/Books/Users/Arangoimp/README.mdpp index 9371839a96..c9e2893f8c 100644 --- a/Documentation/Books/Users/Arangoimp/README.mdpp +++ b/Documentation/Books/Users/Arangoimp/README.mdpp @@ -7,8 +7,8 @@ The most convenient method to import a lot of data into ArangoDB is to use the *arangoimp* command-line tool. It allows you to import data records from a file into an existing database collection. -It is possible to import document keys with the documents using the *_key* -attribute. When importing into an edge collection, it is mandatory that all +It is possible to import [document keys](../Glossary/README.html#document_key) with the documents using the *_key* +attribute. When importing into an [edge collection](../Glossary/README.html#edge_collection), it is mandatory that all imported documents have the *_from* and *_to* attributes, and that they contain valid references. diff --git a/Documentation/Books/Users/Arangorestore/README.mdpp b/Documentation/Books/Users/Arangorestore/README.mdpp index ce7985f810..061bbbbe44 100644 --- a/Documentation/Books/Users/Arangorestore/README.mdpp +++ b/Documentation/Books/Users/Arangorestore/README.mdpp @@ -27,7 +27,7 @@ or use authentication, you can use the following command-line options: * *--server.disable-authentication *: whether or not to use authentication Here's an example of reloading data to a non-standard endpoint, using a dedicated -database name: +[database name](../Glossary/README.html#database_name): unix> arangorestore --server.endpoint tcp://192.168.173.13:8531 --server.username backup --server.database mydb --input-directory "dump" @@ -84,7 +84,7 @@ It can be specified multiple times if required: unix> arangorestore --collection myusers --collection myvalues --input-directory "dump" Collections will be processed by in alphabetical order by _arangorestore_, with all document -collections being processed before all edge collections. This is to ensure that reloading +collections being processed before all [edge collection](../Glossary/README.html#edge_collection)s. This is to ensure that reloading data into edge collections will have the document collections linked in edges (*_from* and *_to* attributes) loaded. @@ -103,7 +103,7 @@ Note that setting *--recycle-ids* to *true* will also cause collections to be (r the target database with the exact same collection id as in the input directory. Any potentially existing collection in the target database with the same collection id will then be dropped. -Setting *--recycle-ids* to *false* or omitting it will only use the collection name from the +Setting *--recycle-ids* to *false* or omitting it will only use the [collection name](../Glossary/README.html#collection_name) from the input directory and allow the target database to create the collection with a different id (though with the same name) than in the input directory. diff --git a/Documentation/Books/Users/Blueprint-Graphs/README.mdpp b/Documentation/Books/Users/Blueprint-Graphs/README.mdpp index 2cf522f31a..55b60efef6 100644 --- a/Documentation/Books/Users/Blueprint-Graphs/README.mdpp +++ b/Documentation/Books/Users/Blueprint-Graphs/README.mdpp @@ -7,7 +7,7 @@ This module is deprecated and will be removed soon. Please use [General Graphs](../General-Graphs/README.md) instead. A Graph consists of vertices and edges. The vertex collection contains the -documents forming the vertices. The edge collection contains the documents +documents forming the vertices. The [edge collection](../Glossary/README.html#edge_collection) contains the documents forming the edges. Together both collections form a graph. Assume that the vertex collection is called `vertices` and the edges collection `edges`, then you can build a graph using the Graph constructor. diff --git a/Documentation/Books/Users/Collections/README.mdpp b/Documentation/Books/Users/Collections/README.mdpp index 5dde7fce02..85bfcfe7d7 100644 --- a/Documentation/Books/Users/Collections/README.mdpp +++ b/Documentation/Books/Users/Collections/README.mdpp @@ -12,15 +12,15 @@ All collections in ArangoDB have an unique identifier and an unique name. ArangoDB internally uses the collection's unique identifier to look up collections. 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 collection - also has an unique name which is specified by the user. To access a collection -from the user perspective, the collection name should be used, i.e.: +also has an unique name which is specified by the user. To access a collection +from the user perspective, the [collection name](../Glossary/README.html#collection_name) should be used, i.e.: !SUBSECTION Collection `db._collection(collection-name)` A collection is created by a ["db._create"](../Collections/DatabaseMethods.md) call. -For example: Assume that the collection identifier is *7254820* and the name is +For example: Assume that the [collection identifier](../Glossary/README.html#collection_identifier) is *7254820* and the name is *demo*, then the collection can be accessed as: db._collection("demo") diff --git a/Documentation/Books/Users/Documents/DocumentAddress.mdpp b/Documentation/Books/Users/Documents/DocumentAddress.mdpp index ccdd25c4c0..203ce9a0e6 100644 --- a/Documentation/Books/Users/Documents/DocumentAddress.mdpp +++ b/Documentation/Books/Users/Documents/DocumentAddress.mdpp @@ -1,6 +1,6 @@ !CHAPTER Address and ETag of a Document -All documents in ArangoDB have a document handle. This handle uniquely defines a +All documents in ArangoDB have a [document handle](../Glossary/README.html#document_handle). This handle uniquely defines a document and is managed by ArangoDB. The interface allows you to access the documents of a collection as: @@ -17,6 +17,6 @@ can leave out the *collection* and use the shortcut: db._document("demo/362549736") -Each document also has a document revision or ETag which is returned in the +Each document also has a [document revision](../Glossary/README.html#document_revision) or ETag which is returned in the *_rev* field when requesting a document. The document's key is returned in the *_key* attribute. diff --git a/Documentation/Books/Users/Documents/README.mdpp b/Documentation/Books/Users/Documents/README.mdpp index 2c1d079c01..5e822aaae8 100644 --- a/Documentation/Books/Users/Documents/README.mdpp +++ b/Documentation/Books/Users/Documents/README.mdpp @@ -6,7 +6,7 @@ documents from the JavaScript shell *arangosh*. For other languages see the corresponding language API. Documents in ArangoDB are JSON objects. These objects can be nested (to any depth) -and may contain lists. Each document is uniquely identified by its document handle. +and may contain lists. Each document is uniquely identified by its [document handle](../Glossary/README.html#document_handle). For example: @@ -29,13 +29,13 @@ For example: } ``` All documents contain special attributes: the document handle in *_id*, the -document's unique key in *_key* and and the ETag aka document revision in +document's unique key in *_key* and and the ETag aka [document revision](../Glossary/README.html#document_revision) in *_rev*. The value of the *_key* attribute can be specified by the user when creating a document. *_id* and *_key* values are immutable once the document has been created. The *_rev* value is maintained by ArangoDB autonomously. A document handle uniquely identifies a document in the database. It is a string and -consists of the collection's name and the document key (_key attribute) separated by /. +consists of the collection's name and the [document key](../Glossary/README.html#document_key) (_key attribute) separated by /. As ArangoDB supports MVCC, documents can exist in more than one revision. The document revision is the MVCC token used to identify a particular diff --git a/Documentation/Books/Users/Edges/README.mdpp b/Documentation/Books/Users/Edges/README.mdpp index 240cd5ff9b..f6ec68e0b4 100644 --- a/Documentation/Books/Users/Edges/README.mdpp +++ b/Documentation/Books/Users/Edges/README.mdpp @@ -6,10 +6,10 @@ corresponding language API. Edges in ArangoDB are special documents. In addition to the internal attributes *_key*, *_id* and *_rev*, they have two attributes *_from* and *_to*, -which contain document handles, namely the start-point and the end-point of the edge. +which contain [document handles](../Glossary/README.html#document_handle), namely the start-point and the end-point of the edge. The values of *_from* and *_to* are immutable once saved. -Edge collections are special collections that store edge documents. Edge documents +[Edge collections](../Glossary/README.html#edge_collection) are special collections that store edge documents. Edge documents are connection documents that reference other documents. The type of a collection must be specified when a collection is created and cannot be changed afterwards. diff --git a/Documentation/Books/Users/Foxx/FoxxController.mdpp b/Documentation/Books/Users/Foxx/FoxxController.mdpp index 15b4047406..33156044c9 100644 --- a/Documentation/Books/Users/Foxx/FoxxController.mdpp +++ b/Documentation/Books/Users/Foxx/FoxxController.mdpp @@ -145,7 +145,7 @@ The *request* object inherits several attributes from the underlying Actions: * *server*: a JSON object with sub-attributes *address* (containing server host name or IP address) and *port* (server port). -* *path*: request URI path, with potential database name stripped off. +* *path*: request URI path, with potential [database name](../Glossary/README.html#database_name) stripped off. * *url*: request URI path + query string, with potential database name stripped off diff --git a/Documentation/Books/Users/Foxx/HandlingRequest.mdpp b/Documentation/Books/Users/Foxx/HandlingRequest.mdpp index 5ff35a7609..957ec0d596 100644 --- a/Documentation/Books/Users/Foxx/HandlingRequest.mdpp +++ b/Documentation/Books/Users/Foxx/HandlingRequest.mdpp @@ -57,7 +57,7 @@ instance if you had two completely independent Foxx applications that both access their own collection *'users'*. To prevent such issues, Foxx provides functions that return an -application-specific collection name. +application-specific [collection name](../Glossary/README.html#collection_name). For example, *applicationContext.collectionName('users')* will return the collection name prefixed with the application name, e.g. "myapp_users". This allows to have a *users* collection which is specific for each diff --git a/Documentation/Books/Users/Foxx/README.mdpp b/Documentation/Books/Users/Foxx/README.mdpp index b0d57970f6..8d413e07ee 100644 --- a/Documentation/Books/Users/Foxx/README.mdpp +++ b/Documentation/Books/Users/Foxx/README.mdpp @@ -62,7 +62,7 @@ used to separate the Foxx applications of different databases running in the same ArangoDB instance. Let's assume for now that you are working in the default database (*_system*), that -is used when no database name is specified otherwise. To use Foxx applications with +is used when no [database name](../Glossary/README.html#database_name) is specified otherwise. To use Foxx applications with the *_system* database, create a sub-directory *_system* inside the *databases* subdirectory. All Foxx applications for the *_system* database will go into this directory. Note: to add a Foxx application for a different databases than *_system*, diff --git a/Documentation/Books/Users/General-Graphs/Management.mdpp b/Documentation/Books/Users/General-Graphs/Management.mdpp index c83b219635..440c19cc00 100644 --- a/Documentation/Books/Users/General-Graphs/Management.mdpp +++ b/Documentation/Books/Users/General-Graphs/Management.mdpp @@ -1,7 +1,7 @@ !CHAPTER Graph Management Before we create our first graph, the philosophy of handling the graph content has to be introduced. -A graph contains of a set of edge definitions each referring to one edge collection and +A graph contains of a set of edge definitions each referring to one [edge collection](../Glossary/README.html#edge_collection) and defining constraints on the vertex collections used as start and end points of the edges. Furthermore a graph can contain an arbitrary amount of vertex collections, called orphan collections, that are not used in any edge definition but should be managed by the graph. In order to create a non empty graph the functionality to create edge definitions has to be introduced first: diff --git a/Documentation/Books/Users/General-Graphs/README.mdpp b/Documentation/Books/Users/General-Graphs/README.mdpp index a0e04b2242..756f323df7 100644 --- a/Documentation/Books/Users/General-Graphs/README.mdpp +++ b/Documentation/Books/Users/General-Graphs/README.mdpp @@ -10,7 +10,7 @@ There is no need to include the referenced collections within the query, this mo A Graph consists of *vertices* and *edges*. Edges are stored as documents in *edge collections*. In general a vertex is stored in a document collection. The type of edges that are allowed within a graph is defined by *edge definitions*: -An edge definition is a combination of a edge collection, and the vertex collections that the edges within this collection can connect. +An edge definition is a combination of a [edge collection](../Glossary/README.html#edge_collection), and the vertex collections that the edges within this collection can connect. A graph can have an arbitrary number of edge definitions and arbitrary many additional vertex collections. !SUBSECTION Warning diff --git a/Documentation/Books/Users/Glossary/README.mdpp b/Documentation/Books/Users/Glossary/README.mdpp new file mode 100644 index 0000000000..476b131691 --- /dev/null +++ b/Documentation/Books/Users/Glossary/README.mdpp @@ -0,0 +1,148 @@ +!CHAPTER Glossary + +!SUBSECTION Collection + +A collection consists of documents. It is uniquely identified by its collection identifier. +It also has a unique name that clients should use to identify and access it. +Collections can be renamed. is will change the collection name, but not the collection identifier. +Collections have a type that is specified by the user when the collection is created. +There are currently two types: document and edge. The default type is document. + +!SUBSECTION Collection Identifier + +A collection identifier identifies a collection in a database. It is a string value and is unique within the database. Up to including ArangoDB 1.1, the collection identifier has been a client's primary means to access collections. Starting with ArangoDB 1.2, clients should instead use a collection's unique name to access a collection instead of its identifier. + +ArangoDB currently uses 64bit unsigned integer values to maintain collection ids internally. When returning collection ids to clients, ArangoDB will put them into a string to ensure the collection id is not clipped by clients that do not support big integers. Clients should treat the collection ids returned by ArangoDB as +opaque strings when they store or use it locally. + + +!SUBSECTION Collection Name + +A collection name identifies a collection in a database. It is a string and is unique within the database. Unlike the collection identifier it is supplied by the creator of the collection. The collection name must consist of letters, digits, and the _ (underscore) and - (dash) characters only. Please refer to @ref NamingConventions for more information on valid collection names. + +!SUBSECTION Database + +ArangoDB can handle multiple databases in the same server instance. Databases can be used to logically group and separate data. An ArangoDB database consists of collections and dedicated database-specific worker processes. + +A database contains its own collections (which cannot be accessed from other databases), Foxx applications, and replication loggers and appliers. Each ArangoDB database contains its own system collections (e.g. _users, _replication, ...). + +There will always be at least one database in ArangoDB. This is the default database, named _system. This database cannot be dropped, and provides special operations for creating, dropping, and enumerating databases. Users can create additional databases and give them unique names to access them later. Database management operations cannot be initiated from out of user-defined databases. + +When ArangoDB is accessed via its HTTP REST API, the database name is read from the first part of the request URI path (e.g. /_db/_system/...). If the request URI does not contain a database name, the database name is automatically determined by the algorithm described in @ref HttpDatabaseMapping. + +!SUBSECTION Database Name + +A single ArangoDB instance can handle multiple databases in parallel. When multiple databases are used, each database must be given a unique name. This name is used to uniquely identify a database. The default database in ArangoDB is named _system. + +The database name is a string consisting of only letters, digits and the _ (underscore) and - (dash) characters. User-defined database names must always start with a letter. Database names is case-sensitive. + +!SUBSECTION Database Organization + +A single ArangoDB instance can handle multiple databases in parallel. By default, there will be at least one database, which is named _system. + +Databases are physically stored in separate sub-directories underneath the database directory, which itself resides in the instance's data directory. + +Each database has its own sub-directory, named database-. The database directory contains sub-directories for the collections of the database, and a file named parameter.json. This file contains the database id and name. + +In an example ArangoDB instance which has two databases, the filesystem layout could look like this: + +``` +data/ # the instance's data directory + databases/ # sub-directory containing all databases' data + database-/ # sub-directory for a single database + parameter.json # file containing database id and name + collection-/ # directory containing data about a collection + database-/ # sub-directory for another database + parameter.json # file containing database id and name + collection-/ # directory containing data about a collection + collection-/ # directory containing data about a collection +``` + +Foxx applications are also organized in database-specific directories inside the application path. The filesystem layout could look like this: + +``` +apps/ # the instance's application directory + system/ # system applications (can be ignored) + databases/ # sub-directory containing database-specific applications + / # sub-directory for a single database + # sub-directory for a single application + # sub-directory for a single application + / # sub-directory for another database + # sub-directory for a single application +``` + +!SUBSECTION Document + +Documents in ArangoDB are JSON objects. These objects can be nested (to any depth) and may contains lists. Each document is uniquely identified by its document handle. + +!SUBSECTION Document ETag + +The document revision enclosed in double quotes. The revision is returned by several HTTP API methods in the Etag HTTP header. + +!SUBSECTION Document Handle + +A document handle uniquely identifies a document in the database. It is a string and consists of the collection's name and the document key (_key attribute) separated by /. + +!SUBSECTION Document Key + +A document key uniquely identifies a document in a given collection. It can and should be used by clients when specific documents are searched. Document keys are stored in the _key attribute of documents. The key values are automatically indexed by ArangoDB in a collection's primary index. Thus looking up a document by its key is regularly a fast operation. The _key value of a document is immutable once the document has been created. + +By default, ArangoDB will auto-generate a document key if no _key attribute is specified, and use the user-specified _key otherwise. + +This behavior can be changed on a per-collection level by creating collections with the keyOptions attribute. + +Using keyOptions it is possible to disallow user-specified keys completely, or to force a specific regime for auto-generating the _key values. + +!SUBSECTION Document Revision + +As ArangoDB supports MVCC, documents can exist in more than one revision. The document revision is the MVCC token used to identify a particular revision of a document. It is a string value currently containing an integer number and is unique within the list of document revisions for a single document. Document revisions can be used to conditionally update, replace or delete documents in the database. In order to find a particular revision of a document, you need the document handle and the document revision. + +ArangoDB currently uses 64bit unsigned integer values to maintain document revisions internally. When returning document revisions to clients, ArangoDB will put them into a string to ensure the revision id is not clipped by clients that do not support big integers. Clients should treat the revision id returned by ArangoDB as an opaque string when they store or use it locally. This will allow ArangoDB to change the format of revision ids later if this should be required. Clients can use revisions ids to perform simple equality/non-equality comparisons (e.g. to check whether a document has changed or not), but they should not use revision ids to perform greater/less than comparisions with them to check if a document revision is older than one another, even if this might work for some cases. + +!SUBSECTION Edge + +Edges in ArangoDB are special documents. In addition to the internal attributes _key, _id and _rev, they have two attributes _from and _to, which contain document handles, namely the start-point and the end-point of the edge. + +The values of _from and _to are immutable once saved. + +!SUBSECTION Edge Collection + +Edge collections are special collection that store edge documents. Edge documents are connection documents that reference other documents. The type of a collection must be specified when a collection is created and cannot be changed afterwards. + +!SUBSECTION Index + +Indexes are used to allow fast access to documents. For each collection there is always the primary index which is a hash index for the document key (_key attribute). This index cannot be dropped or changed. + +Edge collections will also have an automatically created edges index, which cannot be modified. This index provides quick access to documents via the _from and _to attributes. + +Most user-land indexes can be created by defining the names of the attributes which should be indexed. Some index types allow indexing just one attribute (e.g. fulltext index) whereas other index types allow indexing multiple attributes. + +Indexing system attributes such as _id, _key, _from, and _to in user-defined indexes is not supported by any index type. Manually creating an index that relies on any of these attributes is unsupported. + +!SUBSECTION Edges Index + +An edges index is automatically created for edge collections. It contains connections between vertex documents and is invoked when the connecting edges of a vertex are queried. There is no way to explicitly create or delete edge indexes. + +!SUBSECTION Fulltext Index + +A fulltext index can be used to find words, or prefixes of words inside documents. A fulltext index can be set on one attribute only, and will index all words contained in documents that have a textual value in this attribute. Only words with a (specifyable) minimum length are indexed. Word tokenisation is done using the word boundary analysis provided by libicu, which is taking into account the selected language provided at server start. Words are indexed in their lower-cased form. The index supports complete match queries (full words) and prefix queries. + +!SUBSECTION Geo Index + +A geo index is used to find places on the surface of the earth fast. + +!SUBSECTION Index Handle + +An index handle uniquely identifies an index in the database. It is a string and consists of a collection name and an index identifier separated by /. + +!SUBSECTION Hash Index + +A hash index is used to find documents based on examples. A hash index can be created for one or multiple document attributes. + +A hash index will only be used by queries if all indexed attributes are present in the example or search query, and if all attributes are compared using the equality (== operator). That means the hash index does not support range queries. + +If the index is declared unique, then access to the indexed attributes should be fast. The performance degrades if the indexed attribute(s) contain(s) only very few distinct values. + +!SUBSECTION Skiplist Index + +A skiplist is used to find ranges of documents. \ No newline at end of file diff --git a/Documentation/Books/Users/HttpBatchRequest/README.mdpp b/Documentation/Books/Users/HttpBatchRequest/README.mdpp index c7eeaae49b..96e652ddd9 100644 --- a/Documentation/Books/Users/HttpBatchRequest/README.mdpp +++ b/Documentation/Books/Users/HttpBatchRequest/README.mdpp @@ -202,6 +202,6 @@ content-length: 53 Please note that the database used for all part operations of a batch request is determined by scanning the original URL (the URL that contains -*/_api/batch*). It is not possible to override the database name in +*/_api/batch*). It is not possible to override the [database name](../Glossary/README.html#database_name) in part operations of a batch. When doing so, any other database name used in a batch part will be ignored. \ No newline at end of file diff --git a/Documentation/Books/Users/HttpBulkImports/ImportingHeadersAndValues.mdpp b/Documentation/Books/Users/HttpBulkImports/ImportingHeadersAndValues.mdpp index 82aa397101..35c9a4555e 100644 --- a/Documentation/Books/Users/HttpBulkImports/ImportingHeadersAndValues.mdpp +++ b/Documentation/Books/Users/HttpBulkImports/ImportingHeadersAndValues.mdpp @@ -36,7 +36,7 @@ errors occurred. !SECTION Importing into Edge Collections -Please note that when importing documents into an edge collection, it is +Please note that when importing documents into an [edge collection](../Glossary/README.html#edge_collection), it is mandatory that all imported documents contain the *_from* and *_to* attributes, and that these contain references to existing collections. diff --git a/Documentation/Books/Users/HttpBulkImports/README.mdpp b/Documentation/Books/Users/HttpBulkImports/README.mdpp index 5bc50c700f..fb86e54189 100644 --- a/Documentation/Books/Users/HttpBulkImports/README.mdpp +++ b/Documentation/Books/Users/HttpBulkImports/README.mdpp @@ -22,7 +22,7 @@ The *collection* URL parameter must be used to specify the target collection for the import. The optional URL parameter *createCollection* can be used to create a non-existing collection during the import. If not used, importing data into a non-existing collection will produce an error. Please note that the *createCollection* -flag can only be used to create document collections, not edge collections. +flag can only be used to create document collections, not [edge collections](../Glossary/README.html#edge_collection). The *waitForSync* URL parameter can be set to *true* to make the import only return if all documents have been synced to disk. diff --git a/Documentation/Books/Users/HttpCollection/README.mdpp b/Documentation/Books/Users/HttpCollection/README.mdpp index be102d1265..3c9468cd1f 100644 --- a/Documentation/Books/Users/HttpCollection/README.mdpp +++ b/Documentation/Books/Users/HttpCollection/README.mdpp @@ -7,7 +7,7 @@ This is an introduction to ArangoDB's Http interface for collections. !SUBSUBSECTION Collection A collection consists of documents. It is uniquely identified by its -collection identifier. It also has a unique name that clients should +[collection identifier](../Glossary/README.html#collection_identifier). It also has a unique name that clients should use to identify and access it. Collections can be renamed. This will change the collection name, but not the collection identifier. Collections have a type that is specified by the user when the collection diff --git a/Documentation/Books/Users/HttpDatabase/DatabaseEndpoint.mdpp b/Documentation/Books/Users/HttpDatabase/DatabaseEndpoint.mdpp index c4318d8889..7d948b0232 100644 --- a/Documentation/Books/Users/HttpDatabase/DatabaseEndpoint.mdpp +++ b/Documentation/Books/Users/HttpDatabase/DatabaseEndpoint.mdpp @@ -1,6 +1,6 @@ !CHAPTER Database-to-Endpoint Mapping -If a database name is present in the URI as above, ArangoDB will consult the database-to-endpoint +If a [database name](../Glossary/README.html#database_name) is present in the URI as above, ArangoDB will consult the database-to-endpoint mapping for the current endpoint, and validate if access to the database is allowed on the endpoint. If the endpoint is not restricted to a list of databases, ArangoDB will continue with the diff --git a/Documentation/Books/Users/HttpDatabase/NotesOnDatabases.mdpp b/Documentation/Books/Users/HttpDatabase/NotesOnDatabases.mdpp index a02a034205..69075e58f6 100644 --- a/Documentation/Books/Users/HttpDatabase/NotesOnDatabases.mdpp +++ b/Documentation/Books/Users/HttpDatabase/NotesOnDatabases.mdpp @@ -15,7 +15,7 @@ applications until they are explicitly installed for the particular database. ArangoDB can handle multiple databases in the same server instance. Databases can be used to logically group and separate data. An ArangoDB database consists of collections and dedicated database-specific worker processes. A database contains its own collections (which cannot be accessed from other databases), Foxx applications and replication loggers and appliers. Each ArangoDB database contains its own system collections (e.g. _users, _graphs, ...). -There will always be at least one database in ArangoDB. This is the default database named _system. This database cannot be dropped and provides special operations for creating, dropping and enumerating databases. Users can create additional databases and give them unique names to access them later. Database management operations cannot be initiated from out of user-defined databases. +There will always be at least one database in ArangoDB. This is the default [database name](../Glossary/README.html#database_name)d _system. This database cannot be dropped and provides special operations for creating, dropping and enumerating databases. Users can create additional databases and give them unique names to access them later. Database management operations cannot be initiated from out of user-defined databases. When ArangoDB is accessed via its HTTP REST API, the database name is read from the first part of the request URI path (e.g. /_db/_system/...). If the request URI does not contain a database name, the database name is automatically determined by the algorithm described in Database-to-Endpoint Mapping . diff --git a/Documentation/Books/Users/HttpDatabase/README.mdpp b/Documentation/Books/Users/HttpDatabase/README.mdpp index e92b1a0bc0..2d34ca78ed 100644 --- a/Documentation/Books/Users/HttpDatabase/README.mdpp +++ b/Documentation/Books/Users/HttpDatabase/README.mdpp @@ -4,7 +4,7 @@ Any operation triggered via ArangoDB's HTTP REST API is executed in the context of exactly one database. To explicitly specify the database in a request, the request URI must contain -the database name in front of the actual path: +the [database name](../Glossary/README.html#database_name) in front of the actual path: http://localhost:8529/_db/mydb/... diff --git a/Documentation/Books/Users/HttpDocument/AddressAndEtag.mdpp b/Documentation/Books/Users/HttpDocument/AddressAndEtag.mdpp index e258f3bfea..c687ba2733 100644 --- a/Documentation/Books/Users/HttpDocument/AddressAndEtag.mdpp +++ b/Documentation/Books/Users/HttpDocument/AddressAndEtag.mdpp @@ -1,6 +1,6 @@ !CHAPTER Address and ETag of a Document -All documents in ArangoDB have a document handle. This handle uniquely identifies +All documents in ArangoDB have a [document handle](../Glossary/README.html#document_handle). This handle uniquely identifies a document. Any document can be retrieved using its unique URI: http://server:port/_api/document/ @@ -11,7 +11,7 @@ is: http://localhost:8529/_api/document/demo/362549736 -The above URL scheme does not specify a database name explicitly, so the +The above URL scheme does not specify a [database name](../Glossary/README.html#database_name) explicitly, so the default database will be used. To explicitly specify the database context, use the following URL schema: @@ -23,7 +23,7 @@ Example: **Note**: The following examples use the short URL format for brevity. -Each document also has a document revision or etag with is returned in the +Each document also has a [document revision](../Glossary/README.html#document_revision) or etag with is returned in the "ETag" HTTP header when requesting a document. If you obtain a document using *GET* and you want to check if a newer revision diff --git a/Documentation/Books/Users/HttpDocument/README.mdpp b/Documentation/Books/Users/HttpDocument/README.mdpp index 6a872c1298..597789886f 100644 --- a/Documentation/Books/Users/HttpDocument/README.mdpp +++ b/Documentation/Books/Users/HttpDocument/README.mdpp @@ -4,7 +4,7 @@ This is an introduction to ArangoDB's REST interface for documents. -Documents in ArangoDB are JSON objects. These objects can be nested (to any depth) and may contain lists. Each document is uniquely identified by its document handle. +Documents in ArangoDB are JSON objects. These objects can be nested (to any depth) and may contain lists. Each document is uniquely identified by its [document handle](../Glossary/README.html#document_handle). An example document: @@ -28,7 +28,7 @@ An example document: ``` All documents contain special attributes: the document handle in *_id*, the -document's unique key in *_key* and and the etag aka document revision in +document's unique key in *_key* and and the etag aka [document revision](../Glossary/README.html#document_revision) in *_rev*. The value of the *_key* attribute can be specified by the user when creating a document. *_id* and *_key* values are immutable once the document has been created. The *_rev* value is maintained by ArangoDB autonomously. diff --git a/Documentation/Books/Users/HttpEdge/AddressAndEtag.mdpp b/Documentation/Books/Users/HttpEdge/AddressAndEtag.mdpp index 40a812139b..05890b59c1 100644 --- a/Documentation/Books/Users/HttpEdge/AddressAndEtag.mdpp +++ b/Documentation/Books/Users/HttpEdge/AddressAndEtag.mdpp @@ -1,6 +1,6 @@ !CHAPTER Address and ETag of an Edge -All documents in ArangoDB have a document handle. This handle uniquely identifies +All documents in ArangoDB have a [document handle](../Glossary/README.html#document_handle). This handle uniquely identifies a document. Any document can be retrieved using its unique URI: http://server:port/_api/document/ @@ -15,7 +15,7 @@ attribute of the edge, is *demo/362549736*, then the URL of that edge is: http://localhost:8529/_api/edge/demo/362549736 -The above URL scheme does not specify a database name explicitly, so the +The above URL scheme does not specify a [database name](../Glossary/README.html#database_name) explicitly, so the default database will be used. To explicitly specify the database context, use the following URL schema: diff --git a/Documentation/Books/Users/HttpEdge/README.mdpp b/Documentation/Books/Users/HttpEdge/README.mdpp index 13dccb7ff1..bb58c8468b 100644 --- a/Documentation/Books/Users/HttpEdge/README.mdpp +++ b/Documentation/Books/Users/HttpEdge/README.mdpp @@ -17,7 +17,7 @@ are stored in documents in regular collections. CEO. You would express this relationship with the *to* and *_to* attributes - the "normal" collection stores all the properties about the reception, e.g. that 20 people are working there and the room number etc -- *_from* is the document handle of the linked vertex (incoming relation) +- *_from* is the [document handle](../Glossary/README.html#document_handle) of the linked vertex (incoming relation) - *_to* is the document handle of the linked vertex (outgoing relation) !SECTION Documents, Identifiers, Handles diff --git a/Documentation/Books/Users/HttpGharial/Edges.mdpp b/Documentation/Books/Users/HttpGharial/Edges.mdpp index 4196ab7282..b5ef8f5e49 100644 --- a/Documentation/Books/Users/HttpGharial/Edges.mdpp +++ b/Documentation/Books/Users/HttpGharial/Edges.mdpp @@ -5,7 +5,7 @@ @RESTDESCRIPTION Creates a new edge in the collection. Within the body the has to contain a *\_from* and *\_to* value referencing to valid vertices in the graph. -Furthermore the edge has to be valid in the definition of this edge collection. +Furthermore the edge has to be valid in the definition of this [edge collection](../Glossary/README.html#edge_collection). @RESTURLPARAMS diff --git a/Documentation/Books/Users/HttpGharial/Management.mdpp b/Documentation/Books/Users/HttpGharial/Management.mdpp index 81b62af09f..d8473a1092 100644 --- a/Documentation/Books/Users/HttpGharial/Management.mdpp +++ b/Documentation/Books/Users/HttpGharial/Management.mdpp @@ -52,7 +52,7 @@ The body contains the graph configuration that has been stored. @RESTRETURNCODE{409} Returned if there is a conflict storing the graph. -This can occur either if a graph with this name is already stored, or if there is one edge definition with a the same edge collection but a different signature used in any other graph. +This can occur either if a graph with this name is already stored, or if there is one edge definition with a the same [edge collection](../Glossary/README.html#edge_collection) but a different signature used in any other graph. @EXAMPLES diff --git a/Documentation/Books/Users/HttpGharial/README.mdpp b/Documentation/Books/Users/HttpGharial/README.mdpp index dfba42c042..fef4acb1db 100644 --- a/Documentation/Books/Users/HttpGharial/README.mdpp +++ b/Documentation/Books/Users/HttpGharial/README.mdpp @@ -10,7 +10,7 @@ There is no need to include the referenced collections within the query, this mo A Graph consists of *vertices* and *edges*. Edges are stored as documents in *edge collections*. In general a vertex is stored in a document collection. The type of edges that are allowed within a graph is defined by *edge definitions*: -An edge definition is a combination of a edge collection, and the vertex collections that the edges within this collection can connect. +An edge definition is a combination of a [edge collection](../Glossary/README.html#edge_collection), and the vertex collections that the edges within this collection can connect. A graph can have an arbitrary number of edge definitions and arbitrary many additional vertex collections. !SUBSECTION Warning diff --git a/Documentation/Books/Users/HttpGraphs/Edge.mdpp b/Documentation/Books/Users/HttpGraphs/Edge.mdpp index b8804e4ea3..dba2da36d7 100644 --- a/Documentation/Books/Users/HttpGraphs/Edge.mdpp +++ b/Documentation/Books/Users/HttpGraphs/Edge.mdpp @@ -28,7 +28,7 @@ The call expects a JSON hash array as body with the edge properties: Creates an edge in a graph. The call expects a JSON hash array as body with the edge properties: -* _key: The name of the edge (optional, if edge collection allows user defined keys). +* _key: The name of the edge (optional, if [edge collection](../Glossary/README.html#edge_collection) allows user defined keys). * _from: The name of the from vertex. * _to: The name of the to vertex. * $label: A label for the edge (optional). diff --git a/Documentation/Books/Users/HttpIndexes/Fulltext.mdpp b/Documentation/Books/Users/HttpIndexes/Fulltext.mdpp index 722c50f9d5..023764ac55 100644 --- a/Documentation/Books/Users/HttpIndexes/Fulltext.mdpp +++ b/Documentation/Books/Users/HttpIndexes/Fulltext.mdpp @@ -1,6 +1,6 @@ !CHAPTER Fulltext -If a fulltext index exists, then /_api/simple/fulltext will use this index to execute the specified fulltext query. +If a [fulltext index](../Glossary/README.html#fulltext_index) exists, then /_api/simple/fulltext will use this index to execute the specified fulltext query. @startDocuBlock JSF_post_api_index_fulltext diff --git a/Documentation/Books/Users/HttpIndexes/README.mdpp b/Documentation/Books/Users/HttpIndexes/README.mdpp index 0fa4e95933..b3e9a0bcd7 100644 --- a/Documentation/Books/Users/HttpIndexes/README.mdpp +++ b/Documentation/Books/Users/HttpIndexes/README.mdpp @@ -7,8 +7,8 @@ general. There are special sections for various index types. !SUBSUBSECTION Index -Indexes are used to allow fast access to documents. For each collection there is always the primary index which is a hash index for the document key (_key attribute). This index cannot be dropped or changed. -Edge collections will also have an automatically created edges index, which cannot be modified. This index provides quick access to documents via the _from and _to attributes. +Indexes are used to allow fast access to documents. For each collection there is always the primary index which is a hash index for the [document key](../Glossary/README.html#document_key) (_key attribute). This index cannot be dropped or changed. +[edge collections](../Glossary/README.html#edge_collection) will also have an automatically created edges index, which cannot be modified. This index provides quick access to documents via the _from and _to attributes. Most user-land indexes can be created by defining the names of the attributes which should be indexed. Some index types allow indexing just one attribute (e.g. fulltext index) whereas other index types allow indexing multiple attributes. diff --git a/Documentation/Books/Users/HttpTraversal/README.mdpp b/Documentation/Books/Users/HttpTraversal/README.mdpp index 84253aa15e..eb6c425c58 100644 --- a/Documentation/Books/Users/HttpTraversal/README.mdpp +++ b/Documentation/Books/Users/HttpTraversal/README.mdpp @@ -7,7 +7,7 @@ initiated by clients by sending the traversal description for execution to the server. Traversals in ArangoDB are used to walk over a graph -stored in one edge collection. It can easily be described +stored in one [edge collection](../Glossary/README.html#edge_collection). It can easily be described which edges of the graph should be followed and which actions should be performed on each visited vertex. Furthermore the ordering of visiting the nodes can be diff --git a/Documentation/Books/Users/IndexHandling/README.mdpp b/Documentation/Books/Users/IndexHandling/README.mdpp index 321d33381a..b3233aeddf 100644 --- a/Documentation/Books/Users/IndexHandling/README.mdpp +++ b/Documentation/Books/Users/IndexHandling/README.mdpp @@ -12,8 +12,8 @@ There are special sections for !SUBSUBSECTION Index -Indexes are used to allow fast access to documents. For each collection there is always the primary index which is a hash index for the document key (_key attribute). This index cannot be dropped or changed. -Edge collections will also have an automatically created edges index, which cannot be modified. This index provides quick access to documents via the _from and _to attributes. +Indexes are used to allow fast access to documents. For each collection there is always the primary index which is a hash index for the [document key](../Glossary/README.html#document_key) (_key attribute). This index cannot be dropped or changed. +[edge collections](../Glossary/README.html#edge_collection) will also have an automatically created edges index, which cannot be modified. This index provides quick access to documents via the _from and _to attributes. Most user-land indexes can be created by defining the names of the attributes which should be indexed. Some index types allow indexing just one attribute (e.g. fulltext index) whereas other index types allow indexing multiple attributes. diff --git a/Documentation/Books/Users/ModuleGraph/README.mdpp b/Documentation/Books/Users/ModuleGraph/README.mdpp index b348080797..bad6b305f6 100644 --- a/Documentation/Books/Users/ModuleGraph/README.mdpp +++ b/Documentation/Books/Users/ModuleGraph/README.mdpp @@ -5,7 +5,7 @@ !SUBSECTION First Steps with Graphs A Graph consists of vertices and edges. The vertex collection contains the -documents forming the vertices. The edge collection contains the documents +documents forming the vertices. The [edge collection](../Glossary/README.html#edge_collection) contains the documents forming the edges. Together both collections form a graph. Assume that the vertex collection is called *vertices* and the edges collection *edges*, then you can build a graph using the *Graph* constructor. diff --git a/Documentation/Books/Users/SUMMARY.md b/Documentation/Books/Users/SUMMARY.md index ec240cc9a1..7f4b8078cc 100644 --- a/Documentation/Books/Users/SUMMARY.md +++ b/Documentation/Books/Users/SUMMARY.md @@ -224,3 +224,5 @@ * [Attribute Names](NamingConventions/AttributeNames.md) * [Error codes and meanings](ErrorCodes/README.md) + +* [Glossary](Glossary/README.md) diff --git a/Documentation/Books/Users/Sharding/StatusOfImplementation.mdpp b/Documentation/Books/Users/Sharding/StatusOfImplementation.mdpp index 69bc6184bc..edf8a576a9 100644 --- a/Documentation/Books/Users/Sharding/StatusOfImplementation.mdpp +++ b/Documentation/Books/Users/Sharding/StatusOfImplementation.mdpp @@ -78,7 +78,7 @@ road map): maintenance and scaling of a cluster. However, in version 2.0 the cluster layout is static and no redistribution of data between the DBservers or moving of shards between servers is possible. - * At this stage the sharding of an edge collection is independent of + * At this stage the sharding of an [edge collection](../Glossary/README.html#edge_collection) is independent of the sharding of the corresponding vertex collection in a graph. For version 2.2 we plan to synchronize the two, to allow for more efficient graph traversal functions in large, sharded graphs. We diff --git a/Documentation/Books/Users/SimpleQueries/FulltextQueries.mdpp b/Documentation/Books/Users/SimpleQueries/FulltextQueries.mdpp index 44e3b8c2d2..4fd0cd55e5 100644 --- a/Documentation/Books/Users/SimpleQueries/FulltextQueries.mdpp +++ b/Documentation/Books/Users/SimpleQueries/FulltextQueries.mdpp @@ -1,7 +1,7 @@ !CHAPTER Fulltext queries ArangoDB allows to run queries on text contained in document attributes. To use -this, a fulltext index must be defined for the attribute of the collection that +this, a [fulltext index](../Glossary/README.html#fulltext_index) must be defined for the attribute of the collection that contains the text. Creating the index will parse the text in the specified attribute for all documents of the collection. Only documents will be indexed that contain a textual value in the indexed attribute. For such documents, the diff --git a/Documentation/Books/Users/Traversals/ExampleData.mdpp b/Documentation/Books/Users/Traversals/ExampleData.mdpp index 8f8dbac9f2..b6b1a239c2 100644 --- a/Documentation/Books/Users/Traversals/ExampleData.mdpp +++ b/Documentation/Books/Users/Traversals/ExampleData.mdpp @@ -1,6 +1,6 @@ !CHAPTER Example Data -The above examples all use a vertex collection *e* and an edge collection *e*. The vertex +The above examples all use a vertex collection *e* and an [edge collection](../Glossary/README.html#edge_collection) *e*. The vertex collection *v* contains continents, countries, and capitals. The edge collection *e* contains connections between continents and countries, and between countries and capitals. diff --git a/Documentation/Books/Users/Traversals/UsingTraversalObjects.mdpp b/Documentation/Books/Users/Traversals/UsingTraversalObjects.mdpp index a0f538d541..01345b417e 100644 --- a/Documentation/Books/Users/Traversals/UsingTraversalObjects.mdpp +++ b/Documentation/Books/Users/Traversals/UsingTraversalObjects.mdpp @@ -472,7 +472,7 @@ var config = { The edges connected to a vertex are determined by the expander. So far we have used a default expander (the default inbound expander to be precise). The default inbound expander simply enumerates all connected ingoing edges for a vertex, based on the -edge collection specified in the traversal configuration. +[edge collection](../Glossary/README.html#edge_collection) specified in the traversal configuration. There is also a default outbound expander, which will enumerate all connected outgoing edges. Finally, there is an any expander, which will follow both ingoing and outgoing diff --git a/Documentation/Books/Users/WebInterface/README.mdpp b/Documentation/Books/Users/WebInterface/README.mdpp index ee60bbdf89..a115189bde 100644 --- a/Documentation/Books/Users/WebInterface/README.mdpp +++ b/Documentation/Books/Users/WebInterface/README.mdpp @@ -71,7 +71,7 @@ application can be installed multiple times using different mount points. The *Graphs* tab provides a viewer facility for graph data stored in ArangoDB. It allows browsing ArangoDB graphs stored in the *_graphs* system collection or a -graph consisting of an arbitrary vertex and edge collection. +graph consisting of an arbitrary vertex and [edge collection](../Glossary/README.html#edge_collection). Please note that the graph viewer requires client-side SVG and that you need a browser capable of rendering that. Especially Internet Explorer browsers older diff --git a/arangod/Aql/Query.cpp b/arangod/Aql/Query.cpp index cd102e88f0..9a62ff39d2 100644 --- a/arangod/Aql/Query.cpp +++ b/arangod/Aql/Query.cpp @@ -180,6 +180,7 @@ QueryResult Query::execute () { parser.ast()->injectBindParameters(_bindParameters); // optimize the ast parser.ast()->optimize(); + std::cout << "AST: " << triagens::basics::JsonHelper::toString(parser.ast()->toJson(TRI_UNKNOWN_MEM_ZONE)) << "\n"; triagens::arango::AqlTransaction> trx(_vocbase, _collections.collections()); @@ -233,7 +234,6 @@ QueryResult Query::execute () { trx.commit(); QueryResult result(TRI_ERROR_NO_ERROR); - //result.json = parser.ast()->toJson(TRI_UNKNOWN_MEM_ZONE); result.json = json; return result; } diff --git a/arangod/Aql/grammar.y b/arangod/Aql/grammar.y index 35f3d2beaf..14d29bc0c5 100644 --- a/arangod/Aql/grammar.y +++ b/arangod/Aql/grammar.y @@ -269,10 +269,26 @@ collect_statement: } collect_list optional_into { auto list = static_cast(parser->popStack()); - // TODO: check if the following two lines are valid here - parser->ast()->scopes()->endNested(); - parser->ast()->scopes()->start(triagens::aql::AQL_SCOPE_COLLECT); - + if (list == nullptr) { + ABORT_OOM + } + + auto scopes = parser->ast()->scopes(); + + scopes->endNested(); + scopes->start(triagens::aql::AQL_SCOPE_COLLECT); + + size_t const n = list->numMembers(); + for (size_t i = 0; i < n; ++i) { + auto member = list->getMember(i); + + if (member != nullptr) { + TRI_ASSERT(member->type == NODE_TYPE_ASSIGN); + auto v = static_cast(member->getMember(0)->getData()); + scopes->addVariable(v); + } + } + auto node = parser->ast()->createNodeCollect(list, $4); parser->ast()->addOperation(node);