mirror of https://gitee.com/bigwinds/arangodb
updated documentation
This commit is contained in:
Jan Steemann
parent
c709a74c52
commit
d67afddac7
36
CHANGELOG
36
CHANGELOG
|
|
@ -7,15 +7,6 @@ v2.4.0 (XXXX-XX-XX)
|
|||
|
||||
A more detailed description is [here](https://www.arangodb.com/2014/12/08/building-hypermedia-apis-foxxgenerator)
|
||||
|
||||
* removed DEPRECATED replication methods:
|
||||
* `replication.logger.start()`
|
||||
* `replication.logger.stop()`
|
||||
* `replication.logger.properties()`
|
||||
* HTTP PUT `/_api/replication/logger-start`
|
||||
* HTTP PUT `/_api/replication/logger-stop`
|
||||
* HTTP GET `/_api/replication/logger-config`
|
||||
* HTTP PUT `/_api/replication/logger-config`
|
||||
|
||||
* New `Applications` tab in web interface:
|
||||
|
||||
The `applications` tab got a complete redesign.
|
||||
|
|
@ -32,10 +23,11 @@ v2.4.0 (XXXX-XX-XX)
|
|||
To install a new application, a new dialogue is now available.
|
||||
It provides the features already available in the console application `foxx-manager` plus some more:
|
||||
* install an application from Github
|
||||
* install an application from a zip fileBut now also allows to install Applications directly from ArangoDBs App store.
|
||||
* install an application from a zip file
|
||||
* install an application from ArangoDB's application store
|
||||
* create a new application from scratch: this feature uses a generator to
|
||||
create a Foxx application with pre-defined CRUD methods for a given list
|
||||
of collections. The generated foxx app can either be downloaded as a zip file or
|
||||
of collections. The generated Foxx app can either be downloaded as a zip file or
|
||||
be installed on the server. Starting with a new Foxx app has never been easier.
|
||||
|
||||
* fixed issue #1102: Aardvark: Layout bug in documents overview
|
||||
|
|
@ -47,8 +39,6 @@ v2.4.0 (XXXX-XX-XX)
|
|||
|
||||
* fixed issue #1161: Aardvark: Click on Import JSON imports previously uploaded file
|
||||
|
||||
* fixed issue #500: AQL parentheses issue
|
||||
|
||||
* removed configure options `--enable-all-in-one-v8`, `--enable-all-in-one-icu`,
|
||||
and `--enable-all-in-one-libev`.
|
||||
|
||||
|
|
@ -72,7 +62,8 @@ v2.4.0 (XXXX-XX-XX)
|
|||
|
||||
This rule removes FilterNodes and CalculationNodes from an execution plan if the
|
||||
filter is already covered by a previous IndexRangeNode. Removing the CalculationNode
|
||||
and the FilterNode will speed up query execution as computation is saved.
|
||||
and the FilterNode will speed up query execution because the query requires less
|
||||
computation.
|
||||
|
||||
* AQL: range optimizations for IN and OR
|
||||
|
||||
|
|
@ -96,9 +87,9 @@ v2.4.0 (XXXX-XX-XX)
|
|||
(doc.indexedAttribute > 23 && doc.indexedAttribute < 42)
|
||||
RETURN doc
|
||||
|
||||
* fixed missing makeDirectory when fetching a Foxx application from a zip file
|
||||
* fixed issue #500: AQL parentheses issue
|
||||
|
||||
* allow passing subqueries as AQL function parameters without using
|
||||
This change allows passing subqueries as AQL function parameters without using
|
||||
duplicate brackets (e.g. `FUNC(query)` instead of `FUNC((query))`
|
||||
|
||||
* added optional `COUNT` clause to AQL `COLLECT`
|
||||
|
|
@ -115,6 +106,8 @@ v2.4.0 (XXXX-XX-XX)
|
|||
COLLECT WITH COUNT INTO length
|
||||
RETURN length
|
||||
|
||||
* fixed missing makeDirectory when fetching a Foxx application from a zip file
|
||||
|
||||
* fixed issue #1134: Change the default endpoint to localhost
|
||||
|
||||
This change will modify the ip address ArangoDB listens on to 127.0.0.1 by default.
|
||||
|
|
@ -154,8 +147,17 @@ v2.4.0 (XXXX-XX-XX)
|
|||
The HTTP API methods for fetching the replication inventory and for dumping collections
|
||||
also support the `includeSystem` control flag via a URL parameter.
|
||||
|
||||
* removed DEPRECATED replication methods:
|
||||
* `replication.logger.start()`
|
||||
* `replication.logger.stop()`
|
||||
* `replication.logger.properties()`
|
||||
* HTTP PUT `/_api/replication/logger-start`
|
||||
* HTTP PUT `/_api/replication/logger-stop`
|
||||
* HTTP GET `/_api/replication/logger-config`
|
||||
* HTTP PUT `/_api/replication/logger-config`
|
||||
|
||||
v2.3.3 (XXXX-XX-XX)
|
||||
|
||||
v2.3.3 (2014-12-17)
|
||||
-------------------
|
||||
|
||||
* fixed error handling in instanciation of distributed AQL queries, this
|
||||
|
|
|
|||
|
|
@ -0,0 +1,197 @@
|
|||
!CHAPTER Features and Improvements
|
||||
|
||||
The following list shows in detail which features have been added or improved in
|
||||
ArangoDB 2.4. ArangoDB 2.4 also contains several bugfixes that are not listed
|
||||
here. For a list of bugfixes, please consult the CHANGELOG.
|
||||
|
||||
|
||||
!SECTION V8 version upgrade
|
||||
|
||||
The built-in version of V8 has been upgraded from 3.16.14 to 3.29.59.
|
||||
|
||||
|
||||
!SECTION FoxxGenerator
|
||||
|
||||
ArangoDB 2.4 is shipped with FoxxGenerator, a framework for building
|
||||
standardized Hypermedia APIs easily. The generated APIs can be consumed with
|
||||
client tools that understand [Siren](https://github.com/kevinswiber/siren).
|
||||
|
||||
The FoxxGenerator can create APIs based on a semantic description of entities
|
||||
and transitions. A blog series on the use cases and how to use the Foxx generator
|
||||
is here:
|
||||
|
||||
* [part 1](https://www.arangodb.com/2014/11/26/building-hypermedia-api-json)
|
||||
* [part 2](https://www.arangodb.com/2014/12/02/building-hypermedia-apis-design)
|
||||
* [part 3](https://www.arangodb.com/2014/12/08/building-hypermedia-apis-foxxgenerator)
|
||||
|
||||
A cookbook recipe for getting started with FoxxGenerator is [here](https://docs.arangodb.com/cookbook/FoxxGeneratorFirstSteps.html).
|
||||
|
||||
!SECTION AQL improvements
|
||||
|
||||
!SUBSECTION Optimizer improvements
|
||||
|
||||
The AQL optimizer has been enhanced to use of indexes in queries in several
|
||||
additional cases. Filters containing the `IN` operator can now make use of
|
||||
indexes, and multiple OR- or AND-combined filter conditions can now also use
|
||||
indexes if the filter conditions refer to the same indexed attribute.
|
||||
|
||||
Here are a few examples of queries that can now use indexes but couldn't before:
|
||||
|
||||
FOR doc IN collection
|
||||
FILTER doc.indexedAttribute == 1 || doc.indexedAttribute > 99
|
||||
RETURN doc
|
||||
|
||||
FOR doc IN collection
|
||||
FILTER doc.indexedAttribute IN [ 3, 42 ] || doc.indexedAttribute > 99
|
||||
RETURN doc
|
||||
|
||||
FOR doc IN collection
|
||||
FILTER (doc.indexedAttribute > 2 && doc.indexedAttribute < 10) ||
|
||||
(doc.indexedAttribute > 23 && doc.indexedAttribute < 42)
|
||||
RETURN doc
|
||||
|
||||
|
||||
Additionally, the optimizer rule `remove-filter-covered-by-index` has been
|
||||
added. This rule removes FilterNodes and CalculationNodes from an execution
|
||||
plan if the filter condition is already covered by a previous IndexRangeNode.
|
||||
Removing the filter's CalculationNode and the FilterNode itself will speed
|
||||
up query execution because the query requires less computation.
|
||||
|
||||
|
||||
!SUBSECTION Language improvements
|
||||
|
||||
!SUBSUBSECTION `COUNT` clause
|
||||
|
||||
An optional `COUNT` clause was added to the `COLLECT` statement. The `COUNT`
|
||||
clause allows for more efficient counting of values.
|
||||
|
||||
In previous versions of ArangoDB one had to write the following to count
|
||||
documents:
|
||||
|
||||
RETURN LENGTH (
|
||||
FOR doc IN collection
|
||||
FILTER ...some condition...
|
||||
RETURN doc
|
||||
)
|
||||
|
||||
With the `COUNT` clause, the query can be modified to
|
||||
|
||||
FOR doc IN collection
|
||||
FILTER ...some condition...
|
||||
COLLECT WITH COUNT INTO length
|
||||
RETURN length
|
||||
|
||||
The latter query will be much more efficient because it will not produce any
|
||||
intermediate results with need to be shipped from a subquery into the `LENGTH`
|
||||
function.
|
||||
|
||||
The `COUNT` clause can also be used to count the number of items in each group:
|
||||
|
||||
FOR doc IN collection
|
||||
FILTER ...some condition...
|
||||
COLLECT group = doc.group WITH COUNT INTO length
|
||||
return { group: group, length: length }
|
||||
|
||||
|
||||
!SUBSUBSECTION `COLLECT` modifications
|
||||
|
||||
In ArangoDB 2.4, `COLLECT` operations can be made more efficient if only a
|
||||
small fragment of the group values is needed later. For these cases, `COLLECT`
|
||||
provides an optional conversion expression for the `INTO` clause. This
|
||||
expression controls the value that is inserted into the array of group values.
|
||||
It can be used for projections.
|
||||
|
||||
The following query only copies the `dateRegistered` attribute of each document
|
||||
into the groups, potentially saving a lot of memory and computation time
|
||||
compared to copying `doc` completely:
|
||||
|
||||
FOR doc IN collection
|
||||
FILTER ...some condition...
|
||||
COLLECT group = doc.group INTO dates = doc.dateRegistered
|
||||
return { group: group, maxDate: MAX(dates) }
|
||||
|
||||
|
||||
!SUBSUBSECTION Subquery syntax
|
||||
|
||||
In previous versions of ArangoDB, subqueries required extra parentheses
|
||||
around them, and this caused confusion when subqueries were used as function
|
||||
parameters. For example, the following query did not work:
|
||||
|
||||
LET values = LENGTH(
|
||||
FOR doc IN collection RETURN doc
|
||||
)
|
||||
|
||||
but had to be written as follows:
|
||||
|
||||
LET values = LENGTH((
|
||||
FOR doc IN collection RETURN doc
|
||||
))
|
||||
|
||||
This was unintuitive and is fixed in version 2.4 so that both variants of
|
||||
the query are accepted and produce the same result.
|
||||
|
||||
|
||||
!SUBSECTION Web interface
|
||||
|
||||
The `Applications` tab for Foxx applications in the web interface has got
|
||||
a complete redesign.
|
||||
|
||||
It will now only show applications that are currently running in ArangoDB.
|
||||
For a selected application, a new detailed view has been created. This view
|
||||
provides a better overview of the app, e.g.:
|
||||
|
||||
* author
|
||||
* license
|
||||
* version
|
||||
* contributors
|
||||
* download links
|
||||
* API documentation
|
||||
|
||||
Installing a new Foxx application on the server is made easy using the new
|
||||
`Add application` button. The `Add application` dialogue provides all the
|
||||
features already available in the `foxx-manager` console application plus some more:
|
||||
|
||||
* install a Foxx application from Github
|
||||
* install a Foxx application from a zip file
|
||||
* install a Foxx application from ArangoDB's application store
|
||||
* create a new Foxx application from scratch: this feature uses a generator to
|
||||
create a Foxx application with pre-defined CRUD methods for a given list of collections.
|
||||
The generated Foxx app can either be downloaded as a zip file or
|
||||
be installed on the server. Starting with a new Foxx app has never been easier.
|
||||
|
||||
|
||||
!SECTION Miscellaneous improvements
|
||||
|
||||
!SUBSECTION Default endpoint is 127.0.0.1
|
||||
|
||||
The default endpoint for the ArangoDB server has been changed from `0.0.0.0` to
|
||||
`127.0.0.1`. This will make new ArangoDB installations unaccessible from clients other
|
||||
than localhost unless the configuration is changed. This is a security precaution
|
||||
measure that has been requested as a feature a lot of times.
|
||||
|
||||
|
||||
!SUBSECTION System collections in replication
|
||||
|
||||
By default, system collections are now included in replication and all replication API
|
||||
return values. This will lead to user accounts and credentials data being replicated
|
||||
from master to slave servers. This may overwrite slave-specific database users.
|
||||
|
||||
If this is undesired, the `_users` collection can be excluded from replication
|
||||
easily by setting the `includeSystem` attribute to `false` in the following commands:
|
||||
|
||||
* replication.sync({ includeSystem: false });
|
||||
* replication.applier.properties({ includeSystem: false });
|
||||
|
||||
This will exclude all system collections (including `_aqlfunctions`, `_graphs` etc.)
|
||||
from the initial synchronisation and the continuous replication.
|
||||
|
||||
If this is also undesired, it is also possible to specify a list of collections to
|
||||
exclude from the initial synchronisation and the continuous replication using the
|
||||
`restrictCollections` attribute, e.g.:
|
||||
|
||||
replication.applier.properties({
|
||||
includeSystem: true,
|
||||
restrictType: "exclude",
|
||||
restrictCollections: [ "_users", "_graphs", "foo" ]
|
||||
});
|
||||
|
||||
|
|
@ -12,7 +12,8 @@
|
|||
* [Upgrading in general](Installing/Upgrading.md)
|
||||
* [Cluster setup](Installing/Cluster.md)
|
||||
<!-- 2 -->
|
||||
* [Whats New](NewFeatures/NewFeatures23.md)
|
||||
* [Whats New](NewFeatures/NewFeatures24.md)
|
||||
* [Whats New in 2.3](NewFeatures/NewFeatures23.md)
|
||||
* [Whats New in 2.2](NewFeatures/NewFeatures22.md)
|
||||
* [Whats New in 2.1](NewFeatures/NewFeatures21.md)
|
||||
* [First Steps](FirstSteps/README.md)
|
||||
|
|
|
|||
Loading…
Reference in New Issue