Hawkin
/
arangodb
mirror of https://gitee.com/bigwinds/arangodb
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'aql2' of github.com:triAGENS/ArangoDB into aql2

This commit is contained in:
Willi Goesgens 2014-08-05 19:00:05 +02:00
parent a7d241cdd8 8b8346e81e
commit f6f35cab9f
46 changed files with 235 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/Books/Users/Aql/DataModification.mdpp
View File

@ -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

10
Documentation/Books/Users/Aql/Functions.mdpp
View File

@ -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

6
Documentation/Books/Users/Aql/Operations.mdpp
View File

@ -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:
```

4
Documentation/Books/Users/AqlExamples/CollectionQueries.mdpp
View File

@ -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.

2
Documentation/Books/Users/Arangodump/README.mdpp
View File

@ -26,7 +26,7 @@ or use authentication, you can use the following command-line options:
* *--server.disable-authentication <bool>*: 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"

4
Documentation/Books/Users/Arangoimp/README.mdpp
View File

@ -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.

6
Documentation/Books/Users/Arangorestore/README.mdpp
View File

@ -27,7 +27,7 @@ or use authentication, you can use the following command-line options:
* *--server.disable-authentication <bool>*: 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.

2
Documentation/Books/Users/Blueprint-Graphs/README.mdpp
View File

@ -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.

6
Documentation/Books/Users/Collections/README.mdpp
View File

@ -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")

4
Documentation/Books/Users/Documents/DocumentAddress.mdpp
View File

@ -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.

6
Documentation/Books/Users/Documents/README.mdpp
View File

@ -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

4
Documentation/Books/Users/Edges/README.mdpp
View File

@ -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.

2
Documentation/Books/Users/Foxx/FoxxController.mdpp
View File

@ -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

2
Documentation/Books/Users/Foxx/HandlingRequest.mdpp
View File

@ -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

2
Documentation/Books/Users/Foxx/README.mdpp
View File

@ -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*,

2
Documentation/Books/Users/General-Graphs/Management.mdpp
View File

@ -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:

2
Documentation/Books/Users/General-Graphs/README.mdpp
View File

@ -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

148
Documentation/Books/Users/Glossary/README.mdpp Normal file
View File

@ -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-<database id>. 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-<id>/ # sub-directory for a single database
parameter.json # file containing database id and name
collection-<id>/ # directory containing data about a collection
database-<id>/ # sub-directory for another database
parameter.json # file containing database id and name
collection-<id>/ # directory containing data about a collection
collection-<id>/ # 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
<database-name>/ # sub-directory for a single database
<app-name> # sub-directory for a single application
<app-name> # sub-directory for a single application
<database-name>/ # sub-directory for another database
<app-name> # 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.

2
Documentation/Books/Users/HttpBatchRequest/README.mdpp
View File

@ -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.

2
Documentation/Books/Users/HttpBulkImports/ImportingHeadersAndValues.mdpp
View File

@ -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.

2
Documentation/Books/Users/HttpBulkImports/README.mdpp
View File

@ -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.

2
Documentation/Books/Users/HttpCollection/README.mdpp
View File

@ -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

2
Documentation/Books/Users/HttpDatabase/DatabaseEndpoint.mdpp
View File

@ -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

2
Documentation/Books/Users/HttpDatabase/NotesOnDatabases.mdpp
View File

@ -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 .

2
Documentation/Books/Users/HttpDatabase/README.mdpp
View File

@ -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/...

6
Documentation/Books/Users/HttpDocument/AddressAndEtag.mdpp
View File

@ -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/<document-handle>
@ -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

4
Documentation/Books/Users/HttpDocument/README.mdpp
View File

@ -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.

4
Documentation/Books/Users/HttpEdge/AddressAndEtag.mdpp
View File

@ -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/<document-handle>
@ -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:

2
Documentation/Books/Users/HttpEdge/README.mdpp
View File

@ -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

2
Documentation/Books/Users/HttpGharial/Edges.mdpp
View File

@ -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

2
Documentation/Books/Users/HttpGharial/Management.mdpp
View File

@ -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

2
Documentation/Books/Users/HttpGharial/README.mdpp
View File

@ -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

2
Documentation/Books/Users/HttpGraphs/Edge.mdpp
View File

@ -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).

2
Documentation/Books/Users/HttpIndexes/Fulltext.mdpp
View File

@ -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.
<!-- js/actions/api-index.js -->
@startDocuBlock JSF_post_api_index_fulltext

4
Documentation/Books/Users/HttpIndexes/README.mdpp
View File

@ -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.

2
Documentation/Books/Users/HttpTraversal/README.mdpp
View File

@ -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

4
Documentation/Books/Users/IndexHandling/README.mdpp
View File

@ -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.

2
Documentation/Books/Users/ModuleGraph/README.mdpp
View File

@ -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.

2
Documentation/Books/Users/SUMMARY.md
View File

@ -224,3 +224,5 @@
* [Attribute Names](NamingConventions/AttributeNames.md)
<!-- 30 -->
* [Error codes and meanings](ErrorCodes/README.md)
<!-- 31 -->
* [Glossary](Glossary/README.md)

2
Documentation/Books/Users/Sharding/StatusOfImplementation.mdpp
View File

@ -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

2
Documentation/Books/Users/SimpleQueries/FulltextQueries.mdpp
View File

@ -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

2
Documentation/Books/Users/Traversals/ExampleData.mdpp
View File

@ -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.

2
Documentation/Books/Users/Traversals/UsingTraversalObjects.mdpp
View File

@ -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

2
Documentation/Books/Users/WebInterface/README.mdpp
View File

@ -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

2
arangod/Aql/Query.cpp
View File

@ -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<triagens::arango::V8TransactionContext<true>> 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;
}

22
arangod/Aql/grammar.y
View File

@ -269,9 +269,25 @@ collect_statement:
} collect_list optional_into {
auto list = static_cast<AstNode const*>(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<Variable*>(member->getMember(0)->getData());
scopes->addVariable(v);
}
}
auto node = parser->ast()->createNodeCollect(list, $4);