diff --git a/Documentation/Manual/NewFeatures11.md b/Documentation/Manual/NewFeatures11.md index 5b9288b295..ab8b5c7877 100644 --- a/Documentation/Manual/NewFeatures11.md +++ b/Documentation/Manual/NewFeatures11.md @@ -1,41 +1,35 @@ 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(); -Extra Javascript functions have been introduced to create collections: +Extra Javascript functions have been introduced to create collections: arangosh> db._createDocumentCollection("users"); arangosh> db._createEdgeCollection("relationships"); @@ -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} +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. +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. +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. diff --git a/Documentation/Manual/NewFeatures11TOC.md b/Documentation/Manual/NewFeatures11TOC.md new file mode 100644 index 0000000000..0cf91cee0e --- /dev/null +++ b/Documentation/Manual/NewFeatures11TOC.md @@ -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 diff --git a/Documentation/Manual/Upgrading.md b/Documentation/Manual/Upgrading.md index 7d525e20a2..1b2a4824fa 100644 --- a/Documentation/Manual/Upgrading.md +++ b/Documentation/Manual/Upgrading.md @@ -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: -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. diff --git a/Documentation/Manual/FirstStepsArangoDB.md b/Documentation/UserManual/FirstStepsArangoDB.md similarity index 78% rename from Documentation/Manual/FirstStepsArangoDB.md rename to Documentation/UserManual/FirstStepsArangoDB.md index 60f1ebf024..1c799c34e8 100644 --- a/Documentation/Manual/FirstStepsArangoDB.md +++ b/Documentation/UserManual/FirstStepsArangoDB.md @@ -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 one or more directories separated by cola (default: "...") + --javascript.startup-directory startup paths containing the JavaScript files; multiple directories can be separated by cola + --javascript.unit-tests do not start as shell, run unit tests instead + --jslint do not start as shell, run jslint instead + --log.level log level (default: "info") + --max-upload-size maximum size of import chunks (in bytes) (default: 500000) + --no-auto-complete disable auto completion + --no-colors deactivate color support + --pager output pager (default: "less -X -R -F -L") + --pretty-print pretty print values + --quiet no banner + --server.connect-timeout connect timeout in seconds (default: 3) + --server.endpoint endpoint to connect to, use 'none' to start without a server (default: "tcp://127.0.0.1:8529") + --server.password password to use when connecting (leave empty for prompt) + --server.request-timeout request timeout in seconds (default: 300) + --server.username username to use when connecting (default: "root") + --use-pager use pager diff --git a/Documentation/Manual/FirstStepsArangoDBTOC.md b/Documentation/UserManual/FirstStepsArangoDBTOC.md similarity index 66% rename from Documentation/Manual/FirstStepsArangoDBTOC.md rename to Documentation/UserManual/FirstStepsArangoDBTOC.md index 2aee4855cc..5a38afcee8 100644 --- a/Documentation/Manual/FirstStepsArangoDBTOC.md +++ b/Documentation/UserManual/FirstStepsArangoDBTOC.md @@ -7,5 +7,8 @@ TOC {#FirstStepsArangoDBTOC} - @ref FirstStepsArangoDBFirstSteps - @ref FirstStepsArangoDBConnecting - @ref FirstStepsArangoDBQuerying + - @ref FirstStepsArangoDBFE - @ref FirstStepsServerStartStop - - @ref FirstStepsServerStartStopOptions \ No newline at end of file + - @ref FirstStepsServerStartStopOptions + - @ref FirstStepsShellStartStop + - @ref FirstStepsShellStartStopOptions diff --git a/Documentation/Manual/Home.md b/Documentation/UserManual/Home.md similarity index 100% rename from Documentation/Manual/Home.md rename to Documentation/UserManual/Home.md diff --git a/Documentation/arango.template.in b/Documentation/arango.template.in index 15f0e5431b..5cd38b2045 100644 --- a/Documentation/arango.template.in +++ b/Documentation/arango.template.in @@ -221,6 +221,7 @@ ALIASES += \ # navigation ALIASES += \ "NAVIGATE{3}=@htmlonly
prev | home | next
@endhtmlonly" \ + "NAVIGATE_FIRST{2}=@htmlonly
prev | home | next
@endhtmlonly" \ "EMBEDTOC{1}=@if LATEX@else@htmlonly
@endhtmlonly@copydoc \1\n@htmlonly
@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 diff --git a/Documentation/arangodb.css b/Documentation/arangodb.css index 428d2dd2f3..3e5b5e1157 100644 --- a/Documentation/arangodb.css +++ b/Documentation/arangodb.css @@ -85,6 +85,10 @@ margin-bottom: 0px; } +#content div.arangodb ul ul { + margin-bottom: 0px; +} + /* ************************************************************************** */ /* pre */ /* ************************************************************************** */ diff --git a/arangod/Documentation/dba-manual.dox b/arangod/Documentation/dba-manual.dox index 0f081b347e..119a745f50 100644 --- a/arangod/Documentation/dba-manual.dox +++ b/arangod/Documentation/dba-manual.dox @@ -32,11 +32,14 @@ //////////////////////////////////////////////////////////////////////////////// /// @page DbaManual ArangoDB's DBA Manual (@VERSION) /// +/// @NAVIGATE{UserManual,Home,ImpManual} +/// /// @if LATEX ///
    ///
  • @ref DbaManualBasics
    • ///
  • @ref DbaManualAuthentication
    • ///
  • @ref DbaManualDatafileDebugger
    • +///
  • @ref DbaManualEmergencyConsole
    • ///
  • @ref ShellCollection
    • ///
  • @ref ShellIndex
    • ///
  • @ref IndexCap
    • @@ -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 +/// +///
      +///
    • @ref DbaManualEmergencyConsole +///
      • +///
    +//////////////////////////////////////////////////////////////////////////////// + +//////////////////////////////////////////////////////////////////////////////// +/// @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 // ----------------------------------------------------------------------------- diff --git a/arangod/Documentation/imp-manual.dox b/arangod/Documentation/imp-manual.dox index db241b78c9..b7d6d038d6 100644 --- a/arangod/Documentation/imp-manual.dox +++ b/arangod/Documentation/imp-manual.dox @@ -26,7 +26,9 @@ //////////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////////// -/// @page ImpManual ArangoDB Importer Manual (@VERSION) +/// @page ImpManual ArangoDB's Importer Manual (@VERSION) +/// +/// @NAVIGATE{DbaManual,Home,Glossary} /// /// @if LATEX ///
      diff --git a/arangod/Documentation/user-manual.dox b/arangod/Documentation/user-manual.dox index f213b99cdd..ce1a51c811 100644 --- a/arangod/Documentation/user-manual.dox +++ b/arangod/Documentation/user-manual.dox @@ -32,9 +32,10 @@ //////////////////////////////////////////////////////////////////////////////// /// @page UserManual ArangoDB's User Manual (@VERSION) /// +/// @NAVIGATE{Upgrading,Home,DbaManual} +/// /// @if LATEX ///
        -///
      • @ref UserManualBasics
        • ///
      • @ref FirstStepsArangoDB
        • ///
      • @ref UserManualArangosh
        • ///
      • @ref ShellCollection
        • @@ -49,7 +50,6 @@ ///
      • @ref Glossary
        • ///
      /// @else -/// @copydetails UserManualBasicsTOC /// @copydetails FirstStepsArangoDBTOC /// @copydetails UserManualArangoshTOC /// @copydetails ShellCollectionTOC @@ -62,95 +62,6 @@ /// @endif //////////////////////////////////////////////////////////////////////////////// -// ----------------------------------------------------------------------------- -// --SECTION-- USER MANUAL BASICS -// ----------------------------------------------------------------------------- - -//////////////////////////////////////////////////////////////////////////////// -/// @page UserManualBasicsTOC -/// -///
        -///
      • @ref UserManualBasics -///
          -///
        • @ref UserManualServerStartStop -///
            -///
          • @ref UserManualServerStartStopOptions
            • -///
          -///
          • -///
        • @ref UserManualServerFE
          • -///
        • @ref UserManualShellStartStop -///
            -///
          • @ref UserManualShellStartStopOptions
            • -///
          -///
          • -///
        • @ref UserManualServerStartStopDebug -///
          • -///
        -///
        • -///
      -//////////////////////////////////////////////////////////////////////////////// - -//////////////////////////////////////////////////////////////////////////////// -/// @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 // -----------------------------------------------------------------------------