mirror of https://gitee.com/bigwinds/arangodb
Merge branch 'devel' of https://github.com/triAGENS/ArangoDB into devel
This commit is contained in:
Jan Steemann
commit
973d774ff4
|
|
@ -1,37 +1,31 @@
|
|||
New Features in ArangoDB 1.1 {#NewFeatures11}
|
||||
=============================================
|
||||
|
||||
- @ref NewFeatures11CollectionTypes
|
||||
- @ref NewFeatures11BatchRequests
|
||||
- @ref NewFeatures11PartialUpdates
|
||||
- @ref NewFeatures11BluePrintsAPI
|
||||
- @ref NewFeatures11AqlImprovements
|
||||
- @ref NewFeatures11DiskSynchronisation
|
||||
- @ref NewFeatures11ServerStatistics
|
||||
- @ref NewFeatures11Endpoints
|
||||
- @ref NewFeatures11RequestHandling
|
||||
- @ref NewFeatures11V8Options
|
||||
- @ref NewFeatures11Other
|
||||
@NAVIGATE_FIRST{Home,Upgrading}
|
||||
@EMBEDTOC{NewFeatures11TOC}
|
||||
|
||||
Features and Improvements {#NewFeatures11Introduction}
|
||||
======================================================
|
||||
|
||||
# Features and Improvements {#NewFeatures11Introduction}
|
||||
The following list shows in detail which features have been added or
|
||||
improved in ArangoDB 1.1. Additionally, ArangoDB 1.1 contains a lot
|
||||
of bugfixes that are not listed separately.
|
||||
|
||||
The following list shows in detail which features have been added or improved in ArangoDB 1.1.
|
||||
Additionally, ArangoDB 1.1 contains a lot of bugfixes that are not listed separately.
|
||||
|
||||
|
||||
## Collection Types {#NewFeatures11CollectionTypes}
|
||||
Collection Types {#NewFeatures11CollectionTypes}
|
||||
------------------------------------------------
|
||||
|
||||
In ArangoDB 1.1, collections are now explicitly typed:
|
||||
|
||||
- regular documents go into _document_-only collections,
|
||||
- and edges go into _edge_ collections.
|
||||
|
||||
In 1.0, collections were untyped, and edges and documents could be mixed in the same collection.
|
||||
Whether or not a collection was to be treated as an _edge_ or _document_ collection was
|
||||
decided at runtime by looking at the prefix used (e.g. `db.xxx` vs. `edges.xxx`).
|
||||
In 1.0, collections were untyped, and edges and documents could be
|
||||
mixed in the same collection. Whether or not a collection was to be
|
||||
treated as an _edge_ or _document_ collection was decided at runtime
|
||||
by looking at the prefix used (e.g. `db.xxx` vs. `edges.xxx`).
|
||||
|
||||
The explicit collection types used in ArangoDB allow users to query the collection type at
|
||||
runtime and make decisions based on the type:
|
||||
The explicit collection types used in ArangoDB allow users to query
|
||||
the collection type at runtime and make decisions based on the type:
|
||||
|
||||
arangosh> db.users.type();
|
||||
|
||||
|
|
@ -48,131 +42,150 @@ The "traditional" functions are still available:
|
|||
The ArangoDB web interface also allows the explicit creation of _edge_
|
||||
collections.
|
||||
|
||||
Batch Requests {#NewFeatures11BatchRequests}
|
||||
--------------------------------------------
|
||||
|
||||
## Batch Requests {#NewFeatures11BatchRequests}
|
||||
ArangoDB 1.1 provides a new REST API for batch requests at
|
||||
`/_api/batch`.
|
||||
|
||||
ArangoDB 1.1 provides a new REST API for batch requests at `/_api/batch`.
|
||||
Clients can use the API to send multiple requests to ArangoDB at
|
||||
once. They can package multiple requests into just one aggregated
|
||||
request.
|
||||
|
||||
Clients can use the API to send multiple requests to ArangoDB at once. They can
|
||||
package multiple requests into just one aggregated request.
|
||||
ArangoDB will then unpack the aggregated request and process the
|
||||
contained requests one-by-one. When done it will send an aggregated
|
||||
response to the client, that the client can then unpack to get the
|
||||
list of individual responses.
|
||||
|
||||
ArangoDB will then unpack the aggregated request and process the contained requests
|
||||
one-by-one. When done it will send an aggregated response to the client, that the
|
||||
client can then unpack to get the list of individual responses.
|
||||
Using the batch request API may save network overhead because it
|
||||
reduces the number of HTTP requests and responses that clients and
|
||||
ArangoDB need to exchange. This may be especially important if the
|
||||
network is slow or if the individual requests are small and the
|
||||
network overhead per request would be significant.
|
||||
|
||||
Using the batch request API may save network overhead because it reduces the
|
||||
number of HTTP requests and responses that clients and ArangoDB need to exchange.
|
||||
This may be especially important if the network is slow or if the individual
|
||||
requests are small and the network overhead per request would be significant.
|
||||
It should be noted that packing multiple individual requests into one
|
||||
aggregate request on the client side introduces some overhead
|
||||
itself. The same is true for the aggregate request unpacking and
|
||||
assembling on the server side. Using batch requests may still be
|
||||
beneficial in many cases, but it should be obvious that they should be
|
||||
used only when they replace a considerable amount of individual
|
||||
requests.
|
||||
|
||||
It should be noted that packing multiple individual requests into one aggregate
|
||||
request on the client side introduces some overhead itself. The same is true
|
||||
for the aggregate request unpacking and assembling on the server side. Using
|
||||
batch requests may still be beneficial in many cases, but it should be obvious
|
||||
that they should be used only when they replace a considerable amount of
|
||||
individual requests.
|
||||
For more information see @ref HttpBatch and
|
||||
@EXTREF{http://www.arangodb.org/2012/10/04/gain-factor-of-5-using-batch-updates,this
|
||||
blog article}.
|
||||
|
||||
For more information see @ref HttpBatch and @EXTREF{http://www.arangodb.org/2012/10/04/gain-factor-of-5-using-batch-updates,this blog article}.
|
||||
Support for Partial Updates {#NewFeatures11PartialUpdates}
|
||||
----------------------------------------------------------
|
||||
|
||||
The REST API for documents now offers the HTTP PATCH method to
|
||||
partially update documents. A partial update allows specifying only
|
||||
the attributes the change instead of the full document. Internally, it
|
||||
will merge the supplied attributes into the existing document.
|
||||
|
||||
## Support for Partial Updates {#NewFeatures11PartialUpdates}
|
||||
Completely overwriting/replacing entire documents is still available
|
||||
via the HTTP PUT method in ArangoDB 1.0. In _arangosh_, the partial
|
||||
update method is named _update_, and the previously existing _replace_
|
||||
method still performs a replacement of the entire document as before.
|
||||
|
||||
The REST API for documents now offers the HTTP PATCH method to partially update
|
||||
documents. A partial update allows specifying only the attributes the change instead
|
||||
of the full document. Internally, it will merge the supplied attributes into the
|
||||
existing document.
|
||||
|
||||
Completely overwriting/replacing entire documents is still available via the HTTP PUT
|
||||
method in ArangoDB 1.0.
|
||||
In _arangosh_, the partial update method is named _update_, and the previously existing
|
||||
_replace_ method still performs a replacement of the entire document as before.
|
||||
|
||||
This call with replace just the `active` attribute of the document `user`. All other
|
||||
attributes will remain unmodified. The document revision number will of course be updated
|
||||
as updating creates a new revision:
|
||||
This call with replace just the `active` attribute of the document
|
||||
`user`. All other attributes will remain unmodified. The document
|
||||
revision number will of course be updated as updating creates a new
|
||||
revision:
|
||||
|
||||
arangosh> db.users.update(user, { "active" : false });
|
||||
|
||||
Contrary, the `replace` method will replace the entire existing document with the data
|
||||
supplied. All other attributes will be removed. Replacing will also create a new revision:
|
||||
Contrary, the `replace` method will replace the entire existing
|
||||
document with the data supplied. All other attributes will be
|
||||
removed. Replacing will also create a new revision:
|
||||
|
||||
arangosh> db.users.replace(user, { "active" : false });
|
||||
|
||||
For more information, please check @ref RestDocument.
|
||||
|
||||
Blueprints API {#NewFeatures11BluePrintsAPI}
|
||||
--------------------------------------------
|
||||
|
||||
## Blueprints API {#NewFeatures11BluePrintsAPI}
|
||||
|
||||
Blueprints is a property graph model interface with provided implementations.
|
||||
Databases that implement the Blueprints interfaces automatically support
|
||||
Blueprints-enabled applications (@EXTREF{http://tinkerpop.com/,http://tinkerpop.com}).
|
||||
Blueprints is a property graph model interface with provided
|
||||
implementations. Databases that implement the Blueprints interfaces
|
||||
automatically support Blueprints-enabled applications
|
||||
(@EXTREF{http://tinkerpop.com/,http://tinkerpop.com}).
|
||||
|
||||
For more information please refer to @ref HttpBlueprints.
|
||||
|
||||
AQL Improvements {#NewFeatures11AqlImprovements}
|
||||
------------------------------------------------
|
||||
|
||||
## AQL Improvements {#NewFeatures11AqlImprovements}
|
||||
The following functions have been added or extended in the ArangoDB
|
||||
Query Language (AQL) in ArangoDB 1.1:
|
||||
|
||||
The following functions have been added or extended in the ArangoDB Query Language
|
||||
(AQL) in ArangoDB 1.1:
|
||||
- `MERGE_RECURSIVE()`: new function that merges documents recursively. Especially, it will merge
|
||||
sub-attributes, a functionality not provided by the previously existing `MERGE()` function.
|
||||
- `NOT_NULL()`: now works with any number of arguments and returns the first non-null argument.
|
||||
If all arguments are `null`, the function will return `null`, too.
|
||||
- `FIRST_LIST()`: new function that returns the first argument that is a list, and `null`
|
||||
if none of the arguments are lists.
|
||||
- `FIRST_DOCUMENT()`: new function that returns the first argument that is a document, and `null`
|
||||
if none of the arguments are documents.
|
||||
- `MERGE_RECURSIVE()`: new function that merges documents recursively.
|
||||
Especially, it will merge sub-attributes, a functionality not provided
|
||||
by the previously existing `MERGE()` function.
|
||||
- `NOT_NULL()`: now works with any number of arguments and returns the
|
||||
first non-null argument. If all arguments are `null`, the function
|
||||
will return `null`, too.
|
||||
- `FIRST_LIST()`: new function that returns the first argument that is
|
||||
a list, and `null` if none of the arguments are lists.
|
||||
- `FIRST_DOCUMENT()`: new function that returns the first argument
|
||||
that is a document, and `null` if none of the arguments are
|
||||
documents.
|
||||
- `TO_LIST()`: converts the argument into a list.
|
||||
|
||||
|
||||
## Disk Synchronisation Improvements {#NewFeatures11DiskSynchronisation}
|
||||
Disk Synchronisation Improvements {#NewFeatures11DiskSynchronisation}
|
||||
---------------------------------------------------------------------
|
||||
|
||||
### Synchronisation of Shape Data
|
||||
|
||||
ArangoDB 1.1 provides an option `--database.force-sync-shapes` that controls whether
|
||||
shape data (information about document attriubte names and attribute value types)
|
||||
should be synchronised to disk directly after each write, or if synchronisation is
|
||||
allowed to happen asynchronously.
|
||||
The latter options allows ArangoDB to return faster from operations that involve new
|
||||
document shapes.
|
||||
ArangoDB 1.1 provides an option `--database.force-sync-shapes` that
|
||||
controls whether shape data (information about document attriubte
|
||||
names and attribute value types) should be synchronised to disk
|
||||
directly after each write, or if synchronisation is allowed to happen
|
||||
asynchronously. The latter options allows ArangoDB to return faster
|
||||
from operations that involve new document shapes.
|
||||
|
||||
In ArangoDB 1.0, shape information was always synchronised to disk, and users did not
|
||||
have any options. The default value of `--database.force-sync-shapes` in ArangoDB 1.1
|
||||
is `true` so it is fully compatible with ArangoDB 1.0.
|
||||
However, in ArangoDB 1.1 the direct synchronisation can be turned off by setting the
|
||||
value to `false`. Direct synchronisation of shape data will then be disabled for
|
||||
collections that have a `waitForSync` value of `false`.
|
||||
Shape data will always be synchronised directly for collections that have a `waitForSync`
|
||||
value of `true`.
|
||||
In ArangoDB 1.0, shape information was always synchronised to disk,
|
||||
and users did not have any options. The default value of
|
||||
`--database.force-sync-shapes` in ArangoDB 1.1 is `true` so it is
|
||||
fully compatible with ArangoDB 1.0. However, in ArangoDB 1.1 the
|
||||
direct synchronisation can be turned off by setting the value to
|
||||
`false`. Direct synchronisation of shape data will then be disabled
|
||||
for collections that have a `waitForSync` value of `false`. Shape
|
||||
data will always be synchronised directly for collections that have a
|
||||
`waitForSync` value of `true`.
|
||||
|
||||
Still, ArangoDB 1.1 may need to perform less synchronisation when it writes shape data
|
||||
(attribute names and attribute value types of collection documents).
|
||||
Still, ArangoDB 1.1 may need to perform less synchronisation when it
|
||||
writes shape data (attribute names and attribute value types of
|
||||
collection documents).
|
||||
|
||||
Users may benefit if they save documents with many different structures (in terms of
|
||||
document attribute names and attribute value types) in the same collection. If only
|
||||
small amounts of distinct document shapes are used, the effect will not be noticable.
|
||||
Users may benefit if they save documents with many different
|
||||
structures (in terms of document attribute names and attribute value
|
||||
types) in the same collection. If only small amounts of distinct
|
||||
document shapes are used, the effect will not be noticable.
|
||||
|
||||
|
||||
### Finer Control of Disk Sync Behavior for CRUD operations
|
||||
|
||||
ArangoDB stores all document data in memory-mapped files. When adding new documents,
|
||||
updating existing documents or deleting documents, these modifications are appended at
|
||||
the end of the currently used memory-mapped datafile.
|
||||
ArangoDB stores all document data in memory-mapped files. When adding
|
||||
new documents, updating existing documents or deleting documents,
|
||||
these modifications are appended at the end of the currently used
|
||||
memory-mapped datafile.
|
||||
|
||||
It is configurable whether ArangoDB should directly respond then and synchronise the
|
||||
changes to disk asynchronously, or if it should force the synchronisation before
|
||||
responding. The parameter to control this is named `waitForSync` and can be set on a
|
||||
per-collection level.
|
||||
It is configurable whether ArangoDB should directly respond then and
|
||||
synchronise the changes to disk asynchronously, or if it should force
|
||||
the synchronisation before responding. The parameter to control this
|
||||
is named `waitForSync` and can be set on a per-collection level.
|
||||
|
||||
Often, sychronisation is not required on collection level, but on operation level.
|
||||
ArangoDB 1.1 tries to improve on this by providing extra parameters for the REST
|
||||
and Javascript _document_ and _edge_ modification operations.
|
||||
Often, sychronisation is not required on collection level, but on
|
||||
operation level. ArangoDB 1.1 tries to improve on this by providing
|
||||
extra parameters for the REST and Javascript _document_ and _edge_
|
||||
modification operations.
|
||||
|
||||
This parameter can be used to force synchronisation for operations that work on
|
||||
collections that have `waitForSync` set to `false`.
|
||||
This parameter can be used to force synchronisation for operations
|
||||
that work on collections that have `waitForSync` set to `false`.
|
||||
|
||||
The following REST API methods support the parameter `waitForSync` to force
|
||||
synchronisation:
|
||||
The following REST API methods support the parameter `waitForSync` to
|
||||
force synchronisation:
|
||||
|
||||
* `POST /_api/document`: adding a document
|
||||
* `POST /_api/edge`: adding an edge
|
||||
|
|
@ -183,11 +196,12 @@ synchronisation:
|
|||
* `DELETE /_api/document`: delete a document
|
||||
* `DELETE /_api/edge`: delete an edge
|
||||
|
||||
If the `waitForSync` parameter is omitted or set to `false`, the collection-level
|
||||
synchronisation behavior will be applied. Setting the parameter to `true`
|
||||
will force synchronisation.
|
||||
If the `waitForSync` parameter is omitted or set to `false`, the
|
||||
collection-level synchronisation behavior will be applied. Setting the
|
||||
parameter to `true` will force synchronisation.
|
||||
|
||||
The following Javascript methods support forcing synchronisation, too:
|
||||
|
||||
* `save()`
|
||||
* `update()`
|
||||
* `relace()`
|
||||
|
|
@ -197,12 +211,12 @@ Force synchronisation of a save operation:
|
|||
|
||||
> db.users.save({"name":"foo"}, true);
|
||||
|
||||
If the second parameter is omitted or set to `false`, the collection-level
|
||||
synchronisation behavior will be applied. Setting the parameter to `true`
|
||||
will force synchronisation.
|
||||
If the second parameter is omitted or set to `false`, the
|
||||
collection-level synchronisation behavior will be applied. Setting the
|
||||
parameter to `true` will force synchronisation.
|
||||
|
||||
|
||||
## Server Statistics {#NewFeatures11ServerStatistics}
|
||||
Server Statistics {#NewFeatures11ServerStatistics}
|
||||
--------------------------------------------------
|
||||
|
||||
ArangoDB 1.1 allows querying the server status via REST API methods.
|
||||
|
||||
|
|
@ -221,24 +235,28 @@ server connection statistics figures. It has a new tab "Statistics" for this pur
|
|||
For more information on the APIs, please refer to @ref HttpSystemConnectionStatistics
|
||||
and @ref HttpSystemRequestStatistics.
|
||||
|
||||
Endpoints and SSL support {#NewFeatures11Endpoints}
|
||||
---------------------------------------------------
|
||||
|
||||
## Endpoints and SSL support {#NewFeatures11Endpoints}
|
||||
|
||||
ArangoDB can now listen to incoming connections on one or many "endpoint" of different
|
||||
types. In ArangoDB lingo, an endpoint is the combination of a protocol and some
|
||||
configuration for it.
|
||||
ArangoDB can now listen to incoming connections on one or many
|
||||
"endpoint" of different types. In ArangoDB lingo, an endpoint is the
|
||||
combination of a protocol and some configuration for it.
|
||||
|
||||
The currently supported protocol types are:
|
||||
|
||||
- `tcp`: for unencrypted connection over TCP/IP
|
||||
- `ssl`: for secure connections using SSL over TCP/IP
|
||||
- `unix`: for connections over Unix domain sockets
|
||||
|
||||
You should note that the data transferred inside the protocol is still HTTP, regardless
|
||||
of the chosen protocol. The endpoint protocol can thus be understood as the envelope
|
||||
that all HTTP communication is shipped inside.
|
||||
You should note that the data transferred inside the protocol is still
|
||||
HTTP, regardless of the chosen protocol. The endpoint protocol can
|
||||
thus be understood as the envelope that all HTTP communication is
|
||||
shipped inside.
|
||||
|
||||
To specify an endpoint, ArangoDB 1.1 introduces a new option
|
||||
`--server.endpoint`. The values accepted by this option have the
|
||||
following specification syntax:
|
||||
|
||||
To specify an endpoint, ArangoDB 1.1 introduces a new option `--server.endpoint`. The
|
||||
values accepted by this option have the following specification syntax:
|
||||
- `tcp://host:port (HTTP over IPv4)`
|
||||
- `tcp://[host]:port (HTTP over IPv6)`
|
||||
- `ssl://host:port (HTTP over SSL-encrypted IPv4)`
|
||||
|
|
@ -247,50 +265,66 @@ values accepted by this option have the following specification syntax:
|
|||
|
||||
### TCP endpoints
|
||||
|
||||
The configuration options for the `tcp` endpoint type are hostname/ip address and an
|
||||
optional port number. If the port is ommitted, the default port number of 8529 is used.
|
||||
The configuration options for the `tcp` endpoint type are hostname/ip
|
||||
address and an optional port number. If the port is ommitted, the
|
||||
default port number of 8529 is used.
|
||||
|
||||
To make the server listen to connections coming in for IP
|
||||
192.168.173.13 on TCP/IP port 8529:
|
||||
|
||||
To make the server listen to connections coming in for IP 192.168.173.13 on TCP/IP port 8529:
|
||||
> bin/arangod --server.endpoint tcp://192.168.173.13:8529
|
||||
|
||||
To make the server listen to connections coming in for IP 127.0.0.1 TCP/IP port 999:
|
||||
To make the server listen to connections coming in for IP 127.0.0.1
|
||||
TCP/IP port 999:
|
||||
|
||||
> bin/arangod --server.endpoint tcp://127.0.0.1:999
|
||||
|
||||
|
||||
### SSL endpoints
|
||||
|
||||
SSL endpoints can be used for secure, encrypted connections to ArangoDB. The connection is
|
||||
secured using SSL. SSL is computationally intensive so using it will result in an
|
||||
(unavoidable) performance degradation when compared to plain-text requests.
|
||||
SSL endpoints can be used for secure, encrypted connections to
|
||||
ArangoDB. The connection is secured using SSL. SSL is computationally
|
||||
intensive so using it will result in an (unavoidable) performance
|
||||
degradation when compared to plain-text requests.
|
||||
|
||||
The configuration options for the `ssl` endpoint type are the same as for `tcp` endpoints.
|
||||
The configuration options for the `ssl` endpoint type are the same as
|
||||
for `tcp` endpoints.
|
||||
|
||||
To make the server listen to SSL connections coming in for IP
|
||||
192.168.173.13 on TCP/IP port 8529:
|
||||
|
||||
To make the server listen to SSL connections coming in for IP 192.168.173.13 on TCP/IP port 8529:
|
||||
> bin/arangod --server.endpoint ssl://192.168.173.13:8529
|
||||
|
||||
As multiple endpoints can be configured, ArangoDB can serve SSL and non-SSL requests in
|
||||
parallel, provided they use different ports:
|
||||
As multiple endpoints can be configured, ArangoDB can serve SSL and
|
||||
non-SSL requests in parallel, provided they use different ports:
|
||||
|
||||
> bin/arangod --server.endpoint tcp://192.168.173.13:8529 --server.endpoint ssl://192.168.173.13:8530
|
||||
|
||||
### Unix domain socket endpoints
|
||||
|
||||
The `unix` endpoint type can only be used if clients are on the same host as the _arangod_ server.
|
||||
Connections will then be estabished using a Unix domain socket, which is backed by a socket descriptor
|
||||
file. This type of connection should be slightly more efficient than TCP/IP.
|
||||
The `unix` endpoint type can only be used if clients are on the same
|
||||
host as the _arangod_ server. Connections will then be estabished
|
||||
using a Unix domain socket, which is backed by a socket descriptor
|
||||
file. This type of connection should be slightly more efficient than
|
||||
TCP/IP.
|
||||
|
||||
The configuration option for a `unix` endpoint type is the socket descriptor filename:
|
||||
The configuration option for a `unix` endpoint type is the socket
|
||||
descriptor filename:
|
||||
|
||||
To make the server use a Unix domain socket with filename
|
||||
`/var/run/arango.sock`:
|
||||
|
||||
To make the server use a Unix domain socket with filename `/var/run/arango.sock`:
|
||||
> bin/arangod --server.endpoint unix:///var/run/arango.sock
|
||||
|
||||
|
||||
## Improved HTTP Request Handling {#NewFeatures11RequestHandling}
|
||||
Improved HTTP Request Handling {#NewFeatures11RequestHandling}
|
||||
--------------------------------------------------------------
|
||||
|
||||
### Error Handling
|
||||
|
||||
ArangoDB 1.1 better handles malformed HTTP requests than ArangoDB 1.0 did.
|
||||
When it encounters an invalid HTTP request, it might answer with some HTTP status
|
||||
codes that ArangoDB 1.0 did not use:
|
||||
ArangoDB 1.1 better handles malformed HTTP requests than ArangoDB 1.0
|
||||
did. When it encounters an invalid HTTP request, it might answer with
|
||||
some HTTP status codes that ArangoDB 1.0 did not use:
|
||||
|
||||
- `HTTP 411 Length Required` will be returned for requests that have a negative
|
||||
value in their `Content-Length` HTTP header.
|
||||
- `HTTP 413 Request Entity Too Large` will be returned for too big requests. The
|
||||
|
|
@ -298,65 +332,80 @@ codes that ArangoDB 1.0 did not use:
|
|||
- `HTTP 431 Request Header Field Too Large` will be returned for requests with too
|
||||
long HTTP headers. The maximum size per header field is 1 MB at the moment.
|
||||
|
||||
For requests that are not completely shipped from the client to the server, the
|
||||
server will allow the client 90 seconds of time before closing the dangling connection.
|
||||
For requests that are not completely shipped from the client to the
|
||||
server, the server will allow the client 90 seconds of time before
|
||||
closing the dangling connection.
|
||||
|
||||
If the `Content-Length` HTTP header in an incoming request is set and contains a
|
||||
value that is less than the length of the HTTP body sent, the server will return
|
||||
a `HTTP 400 Bad Request`.
|
||||
If the `Content-Length` HTTP header in an incoming request is set and
|
||||
contains a value that is less than the length of the HTTP body sent,
|
||||
the server will return a `HTTP 400 Bad Request`.
|
||||
|
||||
### Keep-Alive
|
||||
|
||||
In version 1.1, ArangoDB will behave as follows when it comes to HTTP keep-alive:
|
||||
- if a client sends a `Connection: close` HTTP header, the server will close the connection as
|
||||
requested
|
||||
- if a client sends a `Connection: keep-alive` HTTP header, the server will not close the
|
||||
connection but keep it alive as requested
|
||||
- if a client does not send any `Connection` HTTP header, the server will assume _keep-alive_
|
||||
if the request was an HTTP/1.1 request, and _close_ if the request was an HTTP/1.0 request
|
||||
- dangling keep-alive connections will be closed automatically by the server after a configurable
|
||||
amount of seconds. To adjust the value, use the new server option `--server.keep-alive-timeout`.
|
||||
- Keep-alive can be turned off in ArangoDB by setting `--server.keep-alive-timeout` to a value of `0`.
|
||||
In version 1.1, ArangoDB will behave as follows when it comes to HTTP
|
||||
keep-alive:
|
||||
|
||||
- if a client sends a `Connection: close` HTTP header, the server will
|
||||
close the connection as requested
|
||||
- if a client sends a `Connection: keep-alive` HTTP header, the server
|
||||
will not close the connection but keep it alive as requested
|
||||
- if a client does not send any `Connection` HTTP header, the server
|
||||
will assume _keep-alive_ if the request was an HTTP/1.1 request, and
|
||||
_close_ if the request was an HTTP/1.0 request
|
||||
- dangling keep-alive connections will be closed automatically by the
|
||||
server after a configurable amount of seconds. To adjust the value,
|
||||
use the new server option `--server.keep-alive-timeout`.
|
||||
- Keep-alive can be turned off in ArangoDB by setting
|
||||
`--server.keep-alive-timeout` to a value of `0`.
|
||||
|
||||
|
||||
### Configurable Backlog
|
||||
|
||||
ArangoDB 1.1 adds an option `--server.backlog-size` to configure the system backlog size.
|
||||
The backlog size controls the maximum number of queued connections and is used by the listen()
|
||||
system call.
|
||||
ArangoDB 1.1 adds an option `--server.backlog-size` to configure the
|
||||
system backlog size. The backlog size controls the maximum number of
|
||||
queued connections and is used by the listen() system call.
|
||||
|
||||
The default value in ArangoDB is 10, the maximum value is platform-dependent.
|
||||
The default value in ArangoDB is 10, the maximum value is
|
||||
platform-dependent.
|
||||
|
||||
Using V8 Options {#NewFeatures11V8Options}
|
||||
------------------------------------------
|
||||
|
||||
## Using V8 Options {#NewFeatures11V8Options}
|
||||
To use arbitrary options the V8 engine provides, ArangoDB 1.1
|
||||
introduces a new startup option `--javascript.v8-options`. All
|
||||
options that shall be passed to V8 without being interpreted by
|
||||
ArangoDB can be put inside this option. ArangoDB itself will ignore
|
||||
these options and will let V8 handle them. It is up to V8 to handle
|
||||
these options and complain about wrong options. In case of invalid
|
||||
options, V8 may refuse to start, which will also abort the startup of
|
||||
ArangoDB.
|
||||
|
||||
To use arbitrary options the V8 engine provides, ArangoDB 1.1 introduces a new startup
|
||||
option `--javascript.v8-options`.
|
||||
All options that shall be passed to V8 without being interpreted by ArangoDB can be put
|
||||
inside this option. ArangoDB itself will ignore these options and will let V8 handle them.
|
||||
It is up to V8 to handle these options and complain about wrong options. In case of invalid
|
||||
options, V8 may refuse to start, which will also abort the startup of ArangoDB.
|
||||
|
||||
To get a list of all options that the V8 engine in the currently used version of ArangoDB
|
||||
supports, you can use the value `--help`, which will just be passed through to V8:
|
||||
To get a list of all options that the V8 engine in the currently used
|
||||
version of ArangoDB supports, you can use the value `--help`, which
|
||||
will just be passed through to V8:
|
||||
|
||||
> bin/arangod --javascript.v8-options "--help" /tmp/voctest
|
||||
|
||||
|
||||
## Other Improvements {#NewFeatures11Other}
|
||||
Other Improvements {#NewFeatures11Other}
|
||||
----------------------------------------
|
||||
|
||||
### Smaller Hash Indexes
|
||||
|
||||
Some internal structures have been adjusted in ArangoDB 1.1 so that hash index entries
|
||||
consume considerably less memory.
|
||||
Some internal structures have been adjusted in ArangoDB 1.1 so that
|
||||
hash index entries consume considerably less memory.
|
||||
|
||||
Installations may benefit if they use unique or non-unqiue hash indexes on collections.
|
||||
Installations may benefit if they use unique or non-unqiue hash
|
||||
indexes on collections.
|
||||
|
||||
|
||||
### arangoimp
|
||||
|
||||
_arangoimp_ now allows specifiying the end-of-line (EOL) character of the input file.
|
||||
This allows better support for files created on Windows systems with `\r\n` EOLs.
|
||||
_arangoimp_ now allows specifiying the end-of-line (EOL) character of
|
||||
the input file. This allows better support for files created on
|
||||
Windows systems with `\r\n` EOLs.
|
||||
|
||||
_arangoimp_ also supports importing input files in TSV format. TSV is a simple separated
|
||||
format such as CSV, but with the tab character as the separator, no quoting for values
|
||||
and thus no support for line breaks inside the values.
|
||||
_arangoimp_ also supports importing input files in TSV format. TSV is
|
||||
a simple separated format such as CSV, but with the tab character as
|
||||
the separator, no quoting for values and thus no support for line
|
||||
breaks inside the values.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,15 @@
|
|||
TOC {#NewFeatures11TOC}
|
||||
=======================
|
||||
|
||||
- @ref NewFeatures11Introduction
|
||||
- @ref NewFeatures11CollectionTypes
|
||||
- @ref NewFeatures11BatchRequests
|
||||
- @ref NewFeatures11PartialUpdates
|
||||
- @ref NewFeatures11BluePrintsAPI
|
||||
- @ref NewFeatures11AqlImprovements
|
||||
- @ref NewFeatures11DiskSynchronisation
|
||||
- @ref NewFeatures11ServerStatistics
|
||||
- @ref NewFeatures11Endpoints
|
||||
- @ref NewFeatures11RequestHandling
|
||||
- @ref NewFeatures11V8Options
|
||||
- @ref NewFeatures11Other
|
||||
|
|
@ -1,44 +1,59 @@
|
|||
Upgrading to ArangoDB 1.1 {#Upgrading}
|
||||
======================================
|
||||
|
||||
ArangoDB 1.1 introduces new features but may in some respect have slightly different behavior than 1.0.
|
||||
@NAVIGATE{NewFeatures11,Home,UserManual}
|
||||
|
||||
This is unavoidable as new features get introduced and others become superfluous.
|
||||
ArangoDB 1.1 introduces new features but may in some respect have
|
||||
slightly different behavior than 1.0.
|
||||
|
||||
The following list contains changes in ArangoDB 1.1 that are not 100% downwards-compatible to ArangoDB 1.0.
|
||||
This is unavoidable as new features get introduced and others become
|
||||
superfluous.
|
||||
|
||||
Existing users of ArangoDB 1.0 should read the list carefully and make sure they have undertaken all
|
||||
necessary steps and precautions before upgrading from ArangoDB 1.0 to ArangoDB 1.1.
|
||||
The following list contains changes in ArangoDB 1.1 that are not 100%
|
||||
downwards-compatible to ArangoDB 1.0.
|
||||
|
||||
## New dependencies
|
||||
Existing users of ArangoDB 1.0 should read the list carefully and make
|
||||
sure they have undertaken all necessary steps and precautions before
|
||||
upgrading from ArangoDB 1.0 to ArangoDB 1.1.
|
||||
|
||||
As ArangoDB 1.1 supports SSL connections, ArangoDB can only be built on servers with the OpenSSL
|
||||
library installed. The OpenSSL is not bundled with ArangoDB and must be installed separately.
|
||||
New dependencies
|
||||
----------------
|
||||
|
||||
As ArangoDB 1.1 supports SSL connections, ArangoDB can only be built
|
||||
on servers with the OpenSSL library installed. The OpenSSL is not
|
||||
bundled with ArangoDB and must be installed separately.
|
||||
|
||||
## Database directory version check and upgrade
|
||||
Database directory version check and upgrade
|
||||
--------------------------------------------
|
||||
|
||||
Starting with ArangoDB 1.1, _arangod_ will perform a database version check at startup.
|
||||
Starting with ArangoDB 1.1, _arangod_ will perform a database version
|
||||
check at startup.
|
||||
|
||||
It will look for a file named _VERSION_ in its database directory. If the file is not present
|
||||
(it will not be present in an ArangoDB 1.0 database), _arangod_ in version 1.1 will refuse to start
|
||||
and ask the user to run the script _arango-upgrade_ first.
|
||||
It will look for a file named _VERSION_ in its database directory. If
|
||||
the file is not present (it will not be present in an ArangoDB 1.0
|
||||
database), _arangod_ in version 1.1 will refuse to start and ask the
|
||||
user to run the script _arango-upgrade_ first.
|
||||
|
||||
If the _VERSION_ file is present but is from a non-matching version of ArangoDB, _arangod_ will also
|
||||
refuse to start and ask the user to run the upgrade script first.
|
||||
This procedure shall ensure that users have full control over when they perform any updates/upgrades
|
||||
of their data, and do not risk running an incompatible tandem of server and database.
|
||||
If the _VERSION_ file is present but is from a non-matching version of
|
||||
ArangoDB, _arangod_ will also refuse to start and ask the user to run
|
||||
the upgrade script first. This procedure shall ensure that users have
|
||||
full control over when they perform any updates/upgrades of their
|
||||
data, and do not risk running an incompatible tandem of server and
|
||||
database.
|
||||
|
||||
ArangoDB users are asked to run _arango-upgrade_ when upgrading from one version of ArangoDB to a
|
||||
higher version (e.g. from 1.0 to 1.1 in this case), but also after pulling the latest ArangoDB source
|
||||
code while staying in the same minor version (e.g. when updating from 1.1-beta1 to 1.1-beta2).
|
||||
ArangoDB users are asked to run _arango-upgrade_ when upgrading from
|
||||
one version of ArangoDB to a higher version (e.g. from 1.0 to 1.1 in
|
||||
this case), but also after pulling the latest ArangoDB source code
|
||||
while staying in the same minor version (e.g. when updating from
|
||||
1.1-beta1 to 1.1-beta2).
|
||||
|
||||
When installing ArangoDB from scratch, users should also run _arango-upgrade_ once to initialise their
|
||||
database directory with some system collections that ArangoDB requires. When not run, _arangod_ will refuse
|
||||
to start as mentioned before.
|
||||
When installing ArangoDB from scratch, users should also run
|
||||
_arango-upgrade_ once to initialise their database directory with some
|
||||
system collections that ArangoDB requires. When not run, _arangod_
|
||||
will refuse to start as mentioned before.
|
||||
|
||||
_arango-upgrade_ can be invoked from the command-line, and takes the database directory as its
|
||||
only argument:
|
||||
_arango-upgrade_ can be invoked from the command-line, and takes the
|
||||
database directory as its only argument:
|
||||
|
||||
> bin/arango-upgrade --database.directory /tmp/voctest
|
||||
|
||||
|
|
@ -52,162 +67,203 @@ only argument:
|
|||
2012-11-21T18:00:40Z [2411] INFO Upgrade script successfully finished
|
||||
2012-11-21T18:00:42Z [2411] INFO ArangoDB has been shut down
|
||||
|
||||
The _arango-upgrade_ will execute the defined tasks to run _arangod_ with all new features and
|
||||
data formats. It should normally run without problems and indicate success at script end. If it detects
|
||||
a problem that it cannot fix, it will halt on the first error and warn the user.
|
||||
The _arango-upgrade_ will execute the defined tasks to run _arangod_
|
||||
with all new features and data formats. It should normally run without
|
||||
problems and indicate success at script end. If it detects a problem
|
||||
that it cannot fix, it will halt on the first error and warn the user.
|
||||
|
||||
Re-executing _arango-upgrade_ will execute only the previously failed and not yet executed tasks.
|
||||
Re-executing _arango-upgrade_ will execute only the previously failed
|
||||
and not yet executed tasks.
|
||||
|
||||
_arango-upgrade_ needs exclusive access to the database, so it cannot be executed while an
|
||||
instance of _arangod_ is currently running.
|
||||
_arango-upgrade_ needs exclusive access to the database, so it cannot
|
||||
be executed while an instance of _arangod_ is currently running.
|
||||
|
||||
|
||||
## Server startup options changes
|
||||
Server startup options changes
|
||||
------------------------------
|
||||
|
||||
### Port options and endpoints
|
||||
|
||||
The following startup options have been removed for _arangod_ in version 1.1:
|
||||
The following startup options have been removed for _arangod_ in
|
||||
version 1.1:
|
||||
|
||||
- `--port`
|
||||
- `--server.port`
|
||||
- `--server.http-port`
|
||||
- `--server.admin-port`
|
||||
|
||||
All these options are replaced by the new `--server.endpoint` option in ArangoDB 1.1.
|
||||
All these options are replaced by the new `--server.endpoint` option
|
||||
in ArangoDB 1.1.
|
||||
|
||||
The server must now be started with a defined endpoint. The new
|
||||
`--server.endpoint` option is required to specify the protocol,
|
||||
hostname and port the server should use when listening for incoming
|
||||
connections.
|
||||
|
||||
The server must now be started with a defined endpoint.
|
||||
The new `--server.endpoint` option is required to specify the protocol, hostname and port the
|
||||
server should use when listening for incoming connections.
|
||||
The `--server.endpoint` option must be specified on server start,
|
||||
either on the command line or via a configuration file, otherwise
|
||||
_arangod_ will refuse to start.
|
||||
|
||||
The `--server.endpoint` option must be specified on server start, either on the command line or via
|
||||
a configuration file, otherwise _arangod_ will refuse to start.
|
||||
The server can be bound to one or multiple endpoints at once. The
|
||||
following endpoint specification sytnax is currently supported:
|
||||
|
||||
The server can be bound to one or multiple endpoints at once. The following endpoint
|
||||
specification sytnax is currently supported:
|
||||
- `tcp://host:port (HTTP over IPv4)`
|
||||
- `tcp://[host]:port (HTTP over IPv6)`
|
||||
- `ssl://host:port (HTTP over SSL-encrypted IPv4)`
|
||||
- `ssl://[host]:port (HTTP over SSL-encrypted IPv6)`
|
||||
- `unix://path/to/socket (HTTP over UNIX socket)`
|
||||
|
||||
An example value for the option is `--server.endpoint tcp://127.0.0.1:8529`.
|
||||
This will make the server listen to requests coming in on IP address 127.0.0.1 on port 8529,
|
||||
and that use HTTP over TCP/IPv4.
|
||||
An example value for the option is `--server.endpoint
|
||||
tcp://127.0.0.1:8529`. This will make the server listen to requests
|
||||
coming in on IP address 127.0.0.1 on port 8529, and that use HTTP over
|
||||
TCP/IPv4.
|
||||
|
||||
### Authorization
|
||||
|
||||
Starting from 1.1, _arangod_ may be started with authentication turned on.
|
||||
When authentication is turned on, all requests incoming to _arangod_ via the HTTP interface must
|
||||
carry an _HTTP authorization_ header with a valid username and password in order to be processed.
|
||||
Clients sending requests without HTTP autorization headers or with invalid usernames/passwords
|
||||
will be rejected by arangod with an HTTP 401 error.
|
||||
Starting from 1.1, _arangod_ may be started with authentication turned
|
||||
on. When authentication is turned on, all requests incoming to
|
||||
_arangod_ via the HTTP interface must carry an _HTTP authorization_
|
||||
header with a valid username and password in order to be processed.
|
||||
Clients sending requests without HTTP autorization headers or with
|
||||
invalid usernames/passwords will be rejected by arangod with an HTTP
|
||||
401 error.
|
||||
|
||||
_arango-upgrade_ will create a default user _root_ with an empty password when run initially.
|
||||
_arango-upgrade_ will create a default user _root_ with an empty
|
||||
password when run initially.
|
||||
|
||||
To turn authorization off, the server can be started with the
|
||||
following command line option:
|
||||
|
||||
To turn authorization off, the server can be started with the following command line option:
|
||||
--server.disable-authentication true
|
||||
|
||||
Of course this option can also be stored in a configuration file.
|
||||
|
||||
|
||||
### HTTP keep-alive
|
||||
|
||||
The following _arangod_ startup options have been removed in ArangoDB 1.1:
|
||||
The following _arangod_ startup options have been removed in ArangoDB
|
||||
1.1:
|
||||
|
||||
- `--server.require-keep-alive`
|
||||
- `--server.secure-require-keep-alive`
|
||||
|
||||
In version 1.1, the server will behave as follows automatically which should be more
|
||||
conforming to the HTTP standard:
|
||||
- if a client sends a `Connection: close` HTTP header, the server will close the connection as
|
||||
requested
|
||||
- if a client sends a `Connection: keep-alive` HTTP header, the server will not close the
|
||||
connection but keep it alive as requested
|
||||
- if a client does not send any `Connection` HTTP header, the server will assume _keep-alive_
|
||||
if the request was an HTTP/1.1 request, and _close_ if the request was an HTTP/1.0 request
|
||||
- dangling keep-alive connections will be closed automatically by the server after a configurable
|
||||
amount of seconds. To adjust the value, use the new server option `--server.keep-alive-timeout`.
|
||||
- Keep-alive can be turned off in ArangoDB by setting `--server.keep-alive-timeout` to a value of `0`.
|
||||
In version 1.1, the server will behave as follows automatically which
|
||||
should be more conforming to the HTTP standard:
|
||||
|
||||
As ArangoDB 1.1 will use keep-alive by default for incoming HTTP/1.1 requests without a
|
||||
`Connection` header, using ArangoDB 1.1 from a browser will likely result in the same connection
|
||||
being re-used. This may be unintuitive because requests from a browser to ArangoDB will
|
||||
effectively be serialised, not parallelised. To conduct parallel requests from a browser, you
|
||||
should either set `--server.keep-alive-timeout` to a value of `0`, or make your browser send
|
||||
`Connection: close` HTTP headers with its requests.
|
||||
- if a client sends a `Connection: close` HTTP header, the server will
|
||||
close the connection as requested
|
||||
- if a client sends a `Connection: keep-alive` HTTP header, the server
|
||||
will not close the connection but keep it alive as requested
|
||||
- if a client does not send any `Connection` HTTP header, the server
|
||||
will assume _keep-alive_ if the request was an HTTP/1.1 request, and
|
||||
_close_ if the request was an HTTP/1.0 request
|
||||
- dangling keep-alive connections will be closed automatically by the
|
||||
server after a configurable amount of seconds. To adjust the value,
|
||||
use the new server option `--server.keep-alive-timeout`.
|
||||
- Keep-alive can be turned off in ArangoDB by setting
|
||||
`--server.keep-alive-timeout` to a value of `0`.
|
||||
|
||||
As ArangoDB 1.1 will use keep-alive by default for incoming HTTP/1.1
|
||||
requests without a `Connection` header, using ArangoDB 1.1 from a
|
||||
browser will likely result in the same connection being re-used. This
|
||||
may be unintuitive because requests from a browser to ArangoDB will
|
||||
effectively be serialised, not parallelised. To conduct parallel
|
||||
requests from a browser, you should either set
|
||||
`--server.keep-alive-timeout` to a value of `0`, or make your browser
|
||||
send `Connection: close` HTTP headers with its requests.
|
||||
|
||||
## Start / stop scripts
|
||||
Start / stop scripts
|
||||
--------------------
|
||||
|
||||
The user used in start and stop scripts has changed from _arango_ to _arangodb_. Furthermore,
|
||||
the start script name itself has changed from _arangod_ to _arangodb_. Additionally, the default
|
||||
database directory name changed from _/var/arangodb_ to _/var/lib/arangodb_.
|
||||
This was done to be more compliant with various Linux policies.
|
||||
The user used in start and stop scripts has changed from _arango_ to
|
||||
_arangodb_. Furthermore, the start script name itself has changed from
|
||||
_arangod_ to _arangodb_. Additionally, the default database directory
|
||||
name changed from _/var/arangodb_ to _/var/lib/arangodb_. This was
|
||||
done to be more compliant with various Linux policies.
|
||||
|
||||
|
||||
## Collection types
|
||||
Collection types
|
||||
----------------
|
||||
|
||||
In ArangoDB 1.1, collection types have been introduced:
|
||||
|
||||
- regular documents go into _document_-only collections,
|
||||
- and edges go into _edge_ collections.
|
||||
|
||||
The prefixing (`db.xxx` and `edges.xxx`) that could be used to access a collection thus works
|
||||
slightly differently in 1.1:
|
||||
The prefixing (`db.xxx` and `edges.xxx`) that could be used to access
|
||||
a collection thus works slightly differently in 1.1:
|
||||
|
||||
`edges.xxx` can still be used to access collections, however, it will not determine the type
|
||||
of existing collections anymore. In 1.0, you could write `edges.xxx.something` and `xxx` was
|
||||
automatically treated as an _edge_ collection.
|
||||
`edges.xxx` can still be used to access collections, however, it will
|
||||
not determine the type of existing collections anymore. In 1.0, you
|
||||
could write `edges.xxx.something` and `xxx` was automatically treated
|
||||
as an _edge_ collection.
|
||||
|
||||
As collections know and save their type in ArangoDB 1.1, this might work slightly differently.
|
||||
The type of existing collections is immutable and not modifiable by changing the prefix (`db` or `edges`).
|
||||
As collections know and save their type in ArangoDB 1.1, this might
|
||||
work slightly differently. The type of existing collections is
|
||||
immutable and not modifiable by changing the prefix (`db` or `edges`).
|
||||
|
||||
In 1.1, _edge_ collections can be created via the following ways:
|
||||
|
||||
- `edges._create()` as in 1.0
|
||||
- addtionally there is a new method `db._createEdgeCollection()`
|
||||
|
||||
To create _document_ collections, the following methods are available:
|
||||
|
||||
- `db._create()` as in 1.0,
|
||||
- additionally there is now `db._createDocumentCollection()`
|
||||
|
||||
Collections in 1.1 are now either _document_-only or _edge_ collections, but the two concepts
|
||||
cannot be mixed in the same collection.
|
||||
Collections in 1.1 are now either _document_-only or _edge_
|
||||
collections, but the two concepts cannot be mixed in the same
|
||||
collection.
|
||||
|
||||
_arango-upgrade_ will determine the types of existing collections from 1.0 once on upgrade,
|
||||
based on the inspection of the first 50 documents in the collection.
|
||||
_arango-upgrade_ will determine the types of existing collections from
|
||||
1.0 once on upgrade, based on the inspection of the first 50 documents
|
||||
in the collection.
|
||||
|
||||
If one of the documents contains either a `_from` or a `_to` attribute, the collection is made an
|
||||
_edge_ collection. Otherwise, the collection is marked as a _document_ collection.
|
||||
If one of the documents contains either a `_from` or a `_to`
|
||||
attribute, the collection is made an _edge_ collection. Otherwise, the
|
||||
collection is marked as a _document_ collection.
|
||||
|
||||
This distinction is important because edges can only be created in _edge_ collections starting
|
||||
with 1.1. User code may need to be adjusted to work with ArangoDB 1.1 if it tries to insert
|
||||
edges into _document_-only collections.
|
||||
This distinction is important because edges can only be created in
|
||||
_edge_ collections starting with 1.1. User code may need to be
|
||||
adjusted to work with ArangoDB 1.1 if it tries to insert edges into
|
||||
_document_-only collections.
|
||||
|
||||
User code must also be adjusted if it uses the `ArangoEdges` or `ArangoEdgesCollection` objects
|
||||
that were present in ArangoDB 1.0 on the server. This only affects user code that was intended
|
||||
to be run on the server, directly in ArangoDB. The `ArangoEdges` or `ArangoEdgesCollection`
|
||||
objects were not exposed to _arangosh_ or any other clients.
|
||||
User code must also be adjusted if it uses the `ArangoEdges` or
|
||||
`ArangoEdgesCollection` objects that were present in ArangoDB 1.0 on
|
||||
the server. This only affects user code that was intended to be run on
|
||||
the server, directly in ArangoDB. The `ArangoEdges` or
|
||||
`ArangoEdgesCollection` objects were not exposed to _arangosh_ or any
|
||||
other clients.
|
||||
|
||||
## arangoimp / arangosh
|
||||
arangoimp / arangosh
|
||||
--------------------
|
||||
|
||||
The parameters `--connect-timeout` and `--request-timeout` for _arangosh_ and _arangoimp_ have been
|
||||
renamed to `--server.connect-timeout` and `--server.request-timeout`.
|
||||
The parameters `--connect-timeout` and `--request-timeout` for
|
||||
_arangosh_ and _arangoimp_ have been renamed to
|
||||
`--server.connect-timeout` and `--server.request-timeout`.
|
||||
|
||||
The parameter `--server` has been removed for both _arangoimp_ and _arangosh_.
|
||||
The parameter `--server` has been removed for both _arangoimp_ and
|
||||
_arangosh_.
|
||||
|
||||
To specify a server to connect to, the client tools now provide an option `--server.endpoint`.
|
||||
This option can be used to specify the protocol, hostname and port for the connection.
|
||||
The default endpoint that is used when none is specified is `tcp://127.0.0.1:8529`.
|
||||
For more information on the endpoint specification syntax, see above.
|
||||
To specify a server to connect to, the client tools now provide an
|
||||
option `--server.endpoint`. This option can be used to specify the
|
||||
protocol, hostname and port for the connection. The default endpoint
|
||||
that is used when none is specified is `tcp://127.0.0.1:8529`. For
|
||||
more information on the endpoint specification syntax, see above.
|
||||
|
||||
The options `--server.username` and `--server.password` have been added for _arangoimp_ and _arangosh_
|
||||
in order to use authorization from these client tools, too.
|
||||
The options `--server.username` and `--server.password` have been
|
||||
added for _arangoimp_ and _arangosh_ in order to use authorization
|
||||
from these client tools, too.
|
||||
|
||||
These options can be used to specify the username and password when connecting via client tools
|
||||
to the _arangod_ server. If no password is given on the command line, _arangoimp_ and _arangosh_
|
||||
will interactively prompt for a password.
|
||||
If no username is specified on the command line, the default user _root_ will be used but there
|
||||
will still be a password prompt.
|
||||
These options can be used to specify the username and password when
|
||||
connecting via client tools to the _arangod_ server. If no password is
|
||||
given on the command line, _arangoimp_ and _arangosh_ will
|
||||
interactively prompt for a password. If no username is specified on
|
||||
the command line, the default user _root_ will be used but there will
|
||||
still be a password prompt.
|
||||
|
||||
Removed functionality
|
||||
---------------------
|
||||
|
||||
## Removed functionality
|
||||
|
||||
In 1.0, there were unfinished REST APIs available at the `/_admin/config` URL suffix.
|
||||
These APIs were stubs only and have been removed in ArangoDB 1.1.
|
||||
In 1.0, there were unfinished REST APIs available at the
|
||||
`/_admin/config` URL suffix. These APIs were stubs only and have been
|
||||
removed in ArangoDB 1.1.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
First Steps with ArangoDB {#FirstStepsArangoDB}
|
||||
===============================================
|
||||
|
||||
@NAVIGATE{UserManualBasics,UserManual,UserManualArangosh}
|
||||
@NAVIGATE_FIRST{UserManual,UserManualArangosh}
|
||||
@EMBEDTOC{FirstStepsArangoDBTOC}
|
||||
|
||||
What is ArangoDB? {#FirstStepsArangoDBIntro}
|
||||
|
|
@ -12,7 +12,7 @@ model for documents, graphs, and key-values. You can easily build high
|
|||
performance applications using a convenient sql-like query language or
|
||||
JavaScript/Ruby extensions.
|
||||
|
||||
The database server `arangod` stores all documents and serves them
|
||||
The database server _arangod_ stores all documents and serves them
|
||||
using a REST interface. There are driver for all major language like
|
||||
Ruby, Python, PHP, JavaScript, and Perl. In the following sections we
|
||||
will use the JavaScript shell to communicate with the database and
|
||||
|
|
@ -73,7 +73,7 @@ For MacOS X:
|
|||
- initialise (or upgrade) the database `/usr/local/bin/arango-upgrade`
|
||||
- and start the server using `/usr/local/sbin/arangod &`
|
||||
|
||||
After these steps there should be a running instance of `arangod` -
|
||||
After these steps there should be a running instance of _arangod_ -
|
||||
the ArangoDB database server.
|
||||
|
||||
unix> ps auxw | fgrep arangod
|
||||
|
|
@ -87,15 +87,15 @@ ArangoDB programs {#FirstStepsArangoDBBinaries}
|
|||
|
||||
The ArangoDB database package comes with the following programs:
|
||||
|
||||
- `arangod`: The ArangoDB database daemon. This server program is
|
||||
- _arangod_: The ArangoDB database daemon. This server program is
|
||||
intended to run as daemon process and to server the various clients
|
||||
connection to the server via TCP / HTTP. See @ref
|
||||
UserManualServerStartStop.
|
||||
- `arango-update`: Used to initialize or update the database.
|
||||
- `arangosh`: The ArangoDB shell. A client that implements a
|
||||
FirstStepsServerStartStop.
|
||||
- _arango-update_: Used to initialize or update the database.
|
||||
- _arangosh_: The ArangoDB shell. A client that implements a
|
||||
read-eval-print loop (REPL) and provides functions to access and
|
||||
administrate the ArangoDB server. See @ref UserManualShellStartStop.
|
||||
- `arangoimp`: A bulk importer for the ArangoDB server.
|
||||
administrate the ArangoDB server. See @ref FirstStepsShellStartStop.
|
||||
- _arangoimp_: A bulk importer for the ArangoDB server.
|
||||
See @ref ImpManual
|
||||
|
||||
|
||||
|
|
@ -125,7 +125,7 @@ Starting the JavaScript shell {#FirstStepsArangoDBConnecting}
|
|||
-------------------------------------------------------------
|
||||
|
||||
The easiest way to connect to the database is the JavaScript shell
|
||||
`arangosh`. You can either start it from the command-line or as an
|
||||
_arangosh_. You can either start it from the command-line or as an
|
||||
embedded version in the browser. Using the command-line tool has the
|
||||
advantage that you can use auto-completion.
|
||||
|
||||
|
|
@ -304,8 +304,26 @@ You can learn all about the query language @ref Aql "here". Note that
|
|||
`_query` is a short-cut for `_createStatement` and `execute`. We will
|
||||
come back to these functions when we talk about cursors.
|
||||
|
||||
Details about Starting the ArangoDB Server {#FirstStepsServerStartStop}
|
||||
=======================================================================
|
||||
ArangoDB's Front-End {#FirstStepsArangoDBFE}
|
||||
--------------------------------------------
|
||||
|
||||
The ArangoDB server has a graphical front-end, which allows you to
|
||||
inspect the current state of the server from within your browser. You
|
||||
can use the front-end using the following URL:
|
||||
|
||||
http://localhost:8529/_admin
|
||||
|
||||
Unless you have loaded an application into the ArangoDB server, which remaps
|
||||
the paths, the front-end will also be available under
|
||||
|
||||
http://localhost:8529/
|
||||
|
||||
The front-end allows you to browse through the collections and
|
||||
documents. If you need to administrate the database, please use
|
||||
the ArangoDB shell described in the next section.
|
||||
|
||||
Details about the ArangoDB Server {#FirstStepsServerStartStop}
|
||||
==============================================================
|
||||
|
||||
The ArangoDB database server has two modes of operation: as server, where it
|
||||
will answer to client requests, and an emergency console, in which you can
|
||||
|
|
@ -398,3 +416,44 @@ more information see @ref CommandLineLogging "here".
|
|||
@CMDOPT{\--daemon}
|
||||
|
||||
Runs the server as a daemon (as a background process).
|
||||
|
||||
Details about the ArangoDB Shell {#FirstStepsShellStartStop}
|
||||
============================================================
|
||||
|
||||
After the server has been @ref FirstStepsServerStartStop "started",
|
||||
you can use the ArangoDB shell (arangosh) to administrate the
|
||||
server. Without any arguments, the ArangoDB shell will try to contact
|
||||
the server on port 8529 on the localhost. For more information see
|
||||
@ref UserManualArangosh. You might need to set additional options
|
||||
(endpoint, username, and password) when connecting:
|
||||
|
||||
unix> ./arangosh --server.endpoint tcp://127.0.0.1:8529 --server.username root
|
||||
|
||||
The shell will print its own version number and, if successfully connected
|
||||
to a server, the version number of the ArangoDB server.
|
||||
|
||||
Command-Line Options {#FirstStepsShellStartStopOptions}
|
||||
-------------------------------------------------------
|
||||
|
||||
Use @LIT{--help} to get a list of command-line options:
|
||||
|
||||
> ./arangosh --help
|
||||
STANDARD options:
|
||||
--help help message
|
||||
--javascript.modules-path <string> one or more directories separated by cola (default: "...")
|
||||
--javascript.startup-directory <string> startup paths containing the JavaScript files; multiple directories can be separated by cola
|
||||
--javascript.unit-tests <string> do not start as shell, run unit tests instead
|
||||
--jslint <string> do not start as shell, run jslint instead
|
||||
--log.level <string> log level (default: "info")
|
||||
--max-upload-size <uint64> maximum size of import chunks (in bytes) (default: 500000)
|
||||
--no-auto-complete disable auto completion
|
||||
--no-colors deactivate color support
|
||||
--pager <string> output pager (default: "less -X -R -F -L")
|
||||
--pretty-print pretty print values
|
||||
--quiet no banner
|
||||
--server.connect-timeout <int64> connect timeout in seconds (default: 3)
|
||||
--server.endpoint <string> endpoint to connect to, use 'none' to start without a server (default: "tcp://127.0.0.1:8529")
|
||||
--server.password <string> password to use when connecting (leave empty for prompt)
|
||||
--server.request-timeout <int64> request timeout in seconds (default: 300)
|
||||
--server.username <string> username to use when connecting (default: "root")
|
||||
--use-pager use pager
|
||||
|
|
@ -7,5 +7,8 @@ TOC {#FirstStepsArangoDBTOC}
|
|||
- @ref FirstStepsArangoDBFirstSteps
|
||||
- @ref FirstStepsArangoDBConnecting
|
||||
- @ref FirstStepsArangoDBQuerying
|
||||
- @ref FirstStepsArangoDBFE
|
||||
- @ref FirstStepsServerStartStop
|
||||
- @ref FirstStepsServerStartStopOptions
|
||||
- @ref FirstStepsShellStartStop
|
||||
- @ref FirstStepsShellStartStopOptions
|
||||
|
|
@ -221,6 +221,7 @@ ALIASES += \
|
|||
# navigation
|
||||
ALIASES += \
|
||||
"NAVIGATE{3}=@htmlonly<div class=\"navigate\"><a href=\"\1.html\">prev</a> | <a href=\"\2.html\">home</a> | <a href=\"\3.html\">next</a></div>@endhtmlonly" \
|
||||
"NAVIGATE_FIRST{2}=@htmlonly<div class=\"navigate\">prev | <a href=\"\1.html\">home</a> | <a href=\"\2.html\">next</a></div>@endhtmlonly" \
|
||||
"EMBEDTOC{1}=@if LATEX@else@htmlonly <div class=\"toc\">@endhtmlonly@copydoc \1\n@htmlonly</div>@endhtmlonly@endif"
|
||||
|
||||
# glossary
|
||||
|
|
@ -713,7 +714,8 @@ WARN_LOGFILE =
|
|||
# directories like "/usr/src/myproject". Separate the files or directories
|
||||
# with spaces.
|
||||
|
||||
INPUT = @srcdir@/Documentation/Manual \
|
||||
INPUT = @srcdir@/Documentation/UserManual \
|
||||
@srcdir@/Documentation/Manual \
|
||||
@srcdir@/Doxygen/js \
|
||||
@srcdir@/arangod \
|
||||
@srcdir@/lib
|
||||
|
|
@ -1833,7 +1835,7 @@ MSCFILE_DIRS =
|
|||
# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
|
||||
# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
|
||||
|
||||
DOT_GRAPH_MAX_NODES = 50
|
||||
DOT_GRAPH_MAX_NODES = 100
|
||||
|
||||
# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
|
||||
# graphs generated by dot. A depth value of 3 means that only nodes reachable
|
||||
|
|
|
|||
|
|
@ -85,6 +85,10 @@
|
|||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
#content div.arangodb ul ul {
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
/* ************************************************************************** */
|
||||
/* pre */
|
||||
/* ************************************************************************** */
|
||||
|
|
|
|||
|
|
@ -32,11 +32,14 @@
|
|||
////////////////////////////////////////////////////////////////////////////////
|
||||
/// @page DbaManual ArangoDB's DBA Manual (@VERSION)
|
||||
///
|
||||
/// @NAVIGATE{UserManual,Home,ImpManual}
|
||||
///
|
||||
/// @if LATEX
|
||||
/// <ul>
|
||||
/// <li>@ref DbaManualBasics</li>
|
||||
/// <li>@ref DbaManualAuthentication</li>
|
||||
/// <li>@ref DbaManualDatafileDebugger</li>
|
||||
/// <li>@ref DbaManualEmergencyConsole</li>
|
||||
/// <li>@ref ShellCollection</li>
|
||||
/// <li>@ref ShellIndex</li>
|
||||
/// <li>@ref IndexCap</li>
|
||||
|
|
@ -51,6 +54,7 @@
|
|||
/// @copydetails DbaManualBasicsTOC
|
||||
/// @copydetails DbaManualAuthenticationTOC
|
||||
/// @copydetails DbaManualDatafileDebuggerTOC
|
||||
/// @copydetails DbaManualEmergencyConsoleTOC
|
||||
/// @copydetails ShellCollectionTOC
|
||||
/// @copydetails ShellIndexTOC
|
||||
/// @copydetails IndexesTOC
|
||||
|
|
@ -203,6 +207,33 @@
|
|||
/// in order to check the consistency of the datafiles and journals.
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
// -----------------------------------------------------------------------------
|
||||
// --SECTION-- DBA MANUAL EMERGENCY CONSOLE
|
||||
// -----------------------------------------------------------------------------
|
||||
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
/// @page DbaManualEmergencyConsoleTOC
|
||||
///
|
||||
/// <ul>
|
||||
/// <li>@ref DbaManualEmergencyConsole
|
||||
/// </li>
|
||||
/// </ul>
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
/// @page DbaManualEmergencyConsole Emergency Console
|
||||
///
|
||||
/// @EMBEDTOC{DbaManualEmergencyConsoleTOC}
|
||||
///
|
||||
/// The following command starts a emergency console. See below for a list of
|
||||
/// frequently used options, see @ref CommandLine "here" for a complete list.
|
||||
///
|
||||
/// @note Never start the emergency console for a database which also has a
|
||||
/// server attached to it. In general the ArangoDB shell is what you want.
|
||||
///
|
||||
/// @EXAMPLE{start-emergency-console,emergency console}
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
// -----------------------------------------------------------------------------
|
||||
// --SECTION-- END-OF-FILE
|
||||
// -----------------------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -26,7 +26,9 @@
|
|||
////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
/// @page ImpManual ArangoDB Importer Manual (@VERSION)
|
||||
/// @page ImpManual ArangoDB's Importer Manual (@VERSION)
|
||||
///
|
||||
/// @NAVIGATE{DbaManual,Home,Glossary}
|
||||
///
|
||||
/// @if LATEX
|
||||
/// <ul>
|
||||
|
|
|
|||
|
|
@ -32,9 +32,10 @@
|
|||
////////////////////////////////////////////////////////////////////////////////
|
||||
/// @page UserManual ArangoDB's User Manual (@VERSION)
|
||||
///
|
||||
/// @NAVIGATE{Upgrading,Home,DbaManual}
|
||||
///
|
||||
/// @if LATEX
|
||||
/// <ul>
|
||||
/// <li>@ref UserManualBasics</li>
|
||||
/// <li>@ref FirstStepsArangoDB</li>
|
||||
/// <li>@ref UserManualArangosh</li>
|
||||
/// <li>@ref ShellCollection</li>
|
||||
|
|
@ -49,7 +50,6 @@
|
|||
/// <li>@ref Glossary</li>
|
||||
/// </ul>
|
||||
/// @else
|
||||
/// @copydetails UserManualBasicsTOC
|
||||
/// @copydetails FirstStepsArangoDBTOC
|
||||
/// @copydetails UserManualArangoshTOC
|
||||
/// @copydetails ShellCollectionTOC
|
||||
|
|
@ -62,95 +62,6 @@
|
|||
/// @endif
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
// -----------------------------------------------------------------------------
|
||||
// --SECTION-- USER MANUAL BASICS
|
||||
// -----------------------------------------------------------------------------
|
||||
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
/// @page UserManualBasicsTOC
|
||||
///
|
||||
/// <ul>
|
||||
/// <li>@ref UserManualBasics
|
||||
/// <ul>
|
||||
/// <li>@ref UserManualServerStartStop
|
||||
/// <ul>
|
||||
/// <li>@ref UserManualServerStartStopOptions</li>
|
||||
/// </ul>
|
||||
/// </li>
|
||||
/// <li>@ref UserManualServerFE</li>
|
||||
/// <li>@ref UserManualShellStartStop
|
||||
/// <ul>
|
||||
/// <li>@ref UserManualShellStartStopOptions</li>
|
||||
/// </ul>
|
||||
/// </li>
|
||||
/// <li>@ref UserManualServerStartStopDebug
|
||||
/// </li>
|
||||
/// </ul>
|
||||
/// </li>
|
||||
/// </ul>
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
/// @page UserManualBasics About ArangoDB
|
||||
///
|
||||
/// @EMBEDTOC{UserManualBasicsTOC}
|
||||
///
|
||||
/// @section UserManualServerFE ArangoDB's Front-End
|
||||
////////////////////////////////////////////////////
|
||||
///
|
||||
/// The ArangoDB server has a graphical front-end, which allows you to inspect
|
||||
/// the current state of the server from within your browser. You can use the
|
||||
/// front-end using the following URL:
|
||||
///
|
||||
/// @LIT{http://localhost:8529/_admin}
|
||||
///
|
||||
/// Unless you have loaded an application into the ArangoDB server, which remaps
|
||||
/// the paths, the front-end will also be available under
|
||||
///
|
||||
/// @LIT{http://localhost:8529/}.
|
||||
///
|
||||
/// The front-end allows you to browse through the collections and
|
||||
/// documents. If you need to administrate the database, please use
|
||||
/// the ArangoDB shell described in the next section.
|
||||
///
|
||||
/// @section UserManualShellStartStop Starting the ArangoDB Shell
|
||||
/////////////////////////////////////////////////////////////////
|
||||
///
|
||||
/// After the server has been @ref UserManualServerStartStop "started",
|
||||
/// you can use the ArangoDB shell (arangosh) to administrate the server. Without
|
||||
/// any arguments, the ArangoDB shell will try to contact the server
|
||||
/// on port 8529 on the localhost. For more information see @ref
|
||||
/// UserManualArangosh.
|
||||
///
|
||||
/// @TINYEXAMPLE{arangosh-start,starting the shell}
|
||||
///
|
||||
/// You might need to set additional options (endpoint, username, and password)
|
||||
/// when connecting:
|
||||
///
|
||||
/// @verbinclude arangosh-start-full
|
||||
///
|
||||
/// The shell will print its own version number and, if successfully connected
|
||||
/// to a server, the version number of the ArangoDB server.
|
||||
///
|
||||
/// @subsection UserManualShellStartStopOptions Command-Line Options
|
||||
////////////////////////////////////////////////////////////////////
|
||||
///
|
||||
/// Use @LIT{\-\-help} to get a list of command-line options:
|
||||
///
|
||||
/// @TINYEXAMPLE{arangosh-options,shell options}
|
||||
///
|
||||
/// @section UserManualServerStartStopDebug Starting the ArangoDB Emergency Console
|
||||
///////////////////////////////////////////////////////////////////////////////////
|
||||
///
|
||||
/// The following command starts a emergency console. See below for a list of
|
||||
/// frequently used options, see @ref CommandLine "here" for a complete list.
|
||||
///
|
||||
/// @note Never start the emergency console for a database which also has a
|
||||
/// server attached to it. In general the ArangoDB shell is what you want.
|
||||
///
|
||||
/// @EXAMPLE{start-emergency-console,emergency console}
|
||||
////////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
// -----------------------------------------------------------------------------
|
||||
// --SECTION-- USER MANUAL ARANGOSH
|
||||
// -----------------------------------------------------------------------------
|
||||
|
|
|
|||
Loading…
Reference in New Issue