1
0
Fork 0
arangodb/Documentation/Manual/NewFeatures14.md

9.9 KiB

New Features in ArangoDB 1.4

@NAVIGATE_NewFeatures14 @EMBEDTOC{NewFeatures14TOC}

Features and Improvements

The following list shows in detail which features have been added or improved in ArangoDB 1.4. ArangoDB 1.4 also contains several bugfixes that are not listed here - see the @EXTREF{https://github.com/triAGENS/ArangoDB/blob/devel/CHANGELOG,CHANGELOG} for details.

Foxx

Foxx Improvements

TODO

Standard Authentication

TODO

Foxx Manager

ArangoDB builds now ship with an additional binary foxx-manager that can be used to conveniently manage Foxx application in an ArangoDB instance. To make it easy to start with Foxx, the foxx-manager provides commands to download example Foxx applications from a central repository at https://github.com/arangodb/foxx-apps, and install them locally:

> foxx-manager update
> foxx-manager install hello-foxx /hello-foxx

This will first mirror the central list of available Foxx applications locally, and after that make the hello-foxx application available in the local ArangoDB database under the URL prefix /hello-foxx.

Multiple Databases

Traditionally ArangoDB provided collections, but no way of grouping them. When an ArangoDB server was used for multiple applications, there could be collection name clashes, so this was worked around by prefixing collection names with unique application names etc.

Since version 1.4, ArangoDB provides databases as the highest level grouping element. Multiple databases can exist in parallel, and each collection belongs to exactly one database. Collection names need to be unique within their database, but not globally. Thus it is now possible to use the same collection name in different databases.

Individual databases are kept relatively separate by ArangoDB. For example, every databases has its own system collections (e.g. _users, _replication). This allows setting up different users for different databases. Replication is also configured on a per-database level. Other data stored in system collections such as graphs and AQL user function definitions are also database-specific.

Server-side actions (including transactions and Foxx) also belong to exactly one database. They are only allowed to access data from their own database, and must not switch to another. AQL queries can also access collections in the current database only. There is no way to refer to collections of another than the current database.

There is no intention to offer multi-database or cross-database operations in future releases.

By default, ArangoDB comes with one database, which is named _system. This database will always be there. Installations that upgrade from older versions to 1.4 will have all their collections be moved into the _system database during the upgrade procedure.

The _system database cannot be dropped, though all user-defined collections in it can be dropped normally if required. All database management operations such as creating new databases, dropping databases, and retrieving the list of existing databases can only be carried out from within the _system database.

All command-line tools (e.g. arangosh, arangoimp, foxx-manager) will connect to the _system database by default. They also provide the option --server.database to connect to a different database, e.g.:

> arangosh --server.database mydb --server.endpoint tcp://127.0.0.1:8529

From within arangosh, the name of the current database can always be retrieved using the db._name() method:

arangosh> db._name(); 
_system

To create a new database, use the db._createDatabase() command (note: you need to be inside the _system database to execute this command):

arangosh> db._createDatabase("mydb"); 

To retrieve the list of available databases, issue the following command from within arangosh (note: you need to be inside the _system database to execute this command):

arangosh> db._listDatabases();

To switch to a different database, use the db._useDatabase() method:

arangosh> db._useDatabase("mydb");

To remove an entire database with all collections, use the db._dropDatabase() method (note: dropping a database can be executed from within the _system database):

arangosh> db._dropDatabase("mydb");

Databases are dropped asynchronously when all clients have disconnected and all references to the database have been garbage-collected. This is similar to how collections are dropped.

Foxx applications are also active on a per-database level. Each database in an ArangoDB instance can have different Foxx applications installed. To install a Foxx application for a specific database, use the --server.database option when invoking the foxx manager binary:

unix> foxx-manager --server.database mydb update
unix> foxx-manager --server.database mydb install hello-foxx /hello-foxx

Runtime Endpoint Management

The ArangoDB server can listen for incoming requests on multiple endpoints.

The endpoints are normally specified either in ArangoDB's configuration file or on the command-line, using the @ref CommandLineArangoEndpoint "--server.endpoint" option. In previous versions of ArangoDB, the endpoints could not be changed while the server was running.

In ArangoDB 1.4, the endpoints can also be changed at runtime. Each endpoint can optionally be restricted to a specific database (or a list of databases). This endpoint-to- database mapping allows the usage of different port numbers for different databases.
This may be useful in multi-tenant setups.

A multi-endpoint setup may also be useful to turn on encrypted communication for just specific databases.

Asynchronous Execution

ArangoDB 1.4 provides an additional mechanism for asynchronous request execution. Clients can optionally mark any request as "to be executed asynchronously". Asynchronous execution decouples the execution from the actual server response, allowing clients to continue working earlier without waiting for the operation to finish.

Asynchronous requests are queued on the server and executed by the server as soon as possible. The maximum size of the queue can be bounded by using the startup option --scheduler.maximal-queue-size.

The results of asynchronously executed requests are either dropped immediately by the server (i.e. fire and forget) or are stored in memory for later retrieval by the client. ArangoDB provides an API for clients to retrieve the status of async jobs, and to retrieve their responses.

Please refer to @ref HttpJob for more details.

Replication

See @ref UserManualReplication for details.

Web Interface Improvements

The web interface now provides a graph viewer on the Graphs tab. The graph viewer can be used to explore and navigate an existing ArangoDB graph. It supports both graphs in the _graphs system collection as well as user-defined graphs that are composed of an arbitrary vertex and edge collection.

The Dashboard tab in the web interface provides an overview of server figures, which can be adjusted to user needs. New figures are polled by the web interface in a configurable interval, and can be graphed as time-series.

The new API provides the full documentation of ArangoDB's built-in HTTP API. This allows browsing the ArangoDB API locally without the need to refer to the arangodb.org website for documentation.

The Applications tab in the web interface provides an improved overview of installed and available Foxx applications.

The AQL Editor now provides some example queries and allows saving user-defined queries for later reuse.

The details view of collections in the web interface now shows more detailed figures and also a collection's available indexes. Indexes can be created and deleted directly from the web interface now.

Command-Line Options added

The following command-line options have been added for arangod in ArangoDB 1.4:

  • --scheduler.maximal-queue-size: limits the size of the asynchronous request execution queue. Please have a look at @ref NewFeatures14Async for more details.

  • --server.authenticate-system-only: require authentication only for requests going to internal APIs, that is URLs starting with /_ (e.g. /_api/...).

  • --server.disable-replication-applier: start the server with all replication appliers disabled. This might be useful if you want to fix a replication setup problem.

  • --server.disable-replication-logger: start the server with all replication loggers disabled. This might be useful if you want to fix a replication setup problem.

  • --log.requests-file: log incoming HTTP requests to a file

  • --log.content-filter: restrict log output to messages containing a specific string only. This is a debugging option.

  • --log.source-filter (renamed from --log.filter): restrict trace/debug log output to messages originated by specific C/C++ source files. This is a debugging option.

The following command-line options have been added for arangosh in 1.4:

  • --server.database: allows specifying the database name for the connection

  • --prompt: allows setting a user-defined prompt in arangosh. A %d in the prompt will be replaced with the name of the current database.

The following command-line options have been added for arangoimp in 1.4:

  • --server.database: allows specifying the database name for the connection