1
0
Fork 0
arangodb/Installation/debian/changelog

5229 lines
221 KiB
Plaintext

arangodb (2.5.1-1.1) stable; urgency=low
* Changed to Version 2.5.1
* added option `--database.ignore-logfile-errors`
This option controls how collection datafiles with a CRC mismatch are treated.
If set to `false`, CRC mismatch errors in collection datafiles will lead
to a collection not being loaded at all. If a collection needs to be loaded
during WAL recovery, the WAL recovery will also abort (if not forced with
`--wal.ignore-recovery-errors true`). Setting this flag to `false` protects
users from unintentionally using a collection with corrupted datafiles, from
which only a subset of the original data can be recovered.
If set to `true`, CRC mismatch errors in collection datafiles will lead to
the datafile being partially loaded. All data up to until the mismatch will
be loaded. This will enable users to continue with a collection datafiles
that are corrupted, but will result in only a partial load of the data.
The WAL recovery will still abort when encountering a collection with a
corrupted datafile, at least if `--wal.ignore-recovery-errors` is not set to
`true`.
The default value is *true*, so for collections with corrupted datafiles
there might be partial data loads once the WAL recovery has finished. If
the WAL recovery will need to load a collection with a corrupted datafile,
it will still stop when using the default values.
* INCOMPATIBLE CHANGE:
make the arangod server refuse to start if during startup it finds a non-readable
`parameter.json` file for a database or a collection.
Stopping the startup process in this case requires manual intervention (fixing
the unreadable files), but prevents follow-up errors due to ignored databases or
collections from happening.
* datafiles and `parameter.json` files written by arangod are now created with read and write
privileges for the arangod process user, and with read and write prileges for the arangod
process group.
Previously, these files were created with user read and write permissions only.
* INCOMPATIBLE CHANGE:
abort WAL recovery if one of the collection's datafiles cannot be opened
* INCOMPATIBLE CHANGE:
never try to raise the privileges after dropping them, this can lead to a race condition while
running the recovery
If you require to run ArangoDB on a port lower than 1024, you must run ArangoDB as root.
* fixed inefficiencies in `remove` methods of general-graph module
* added option `--database.slow-query-threshold` for controlling the default AQL slow query
threshold value on server start
* add system error strings for windows on many places
* rework service startup so we anounce 'RUNNING' only when we're finished starting.
* use the windows eventlog for FATAL and ERROR - log messages
* fix service handling in NSIS windows installer, specify human readable name
* add the ICU_DATA environment variable to the fatal error messages
* fixed issue #1265: arangod crashed with SIGSEGV
* fixed issue #1241: Wildcards in examples
-- ArangoDB Maintainer <info@arangodb.org> Fri, 20 Mar 2015 00:36:29 +0100
arangodb (2.5.0-1.1) stable; urgency=low
* Changed to Version 2.5.0
* installer fixes for Windows
* fix for downloading Foxx
-- ArangoDB Maintainer <info@arangodb.org> Tue, 10 Mar 2015 16:59:45 +0100
arangodb (2.5.0b4-1.1) stable; urgency=low
* Changed to Version 2.5.0-beta4
* fixed issue #1247: debian init script problems
-- ArangoDB Maintainer <info@arangodb.org> Thu, 05 Mar 2015 16:30:45 +0100
arangodb (2.5.0b3-1.1) stable; urgency=low
* Changed to Version 2.5.0-beta3
* fix windows install path calculation in arango
* fix windows logging of long strings
* fix possible undefinedness of const strings in windows
-- ArangoDB Maintainer <info@arangodb.org> Fri, 27 Feb 2015 18:36:49 +0100
arangodb (2.5.0b2-1.1) stable; urgency=low
* Changed to Version 2.5.0-beta2
* fixed issue #1230: API: document/col-name/_key and cursor return different floats
* front-end: dashboard tries not to (re)load statistics if user has no access
* V8: Upgrade to version 3.31.74.1
* etcd: Upgrade to version 2.0 - This requires go 1.3 to compile at least.
* refuse to startup if ICU wasn't initialized, this will i.e. prevent errors from being printed,
and libraries from being loaded.
* front-end: unwanted removal of index table header after creating new index
* fixed issue #1248: chrome: applications filtering not working
* fixed issue #1198: queries remain in aql editor (front-end) if you navigate through different tabs
* Simplify usage of Foxx
Thanks to our user feedback we learned that Foxx is a powerful, yet rather complicated concept.
With this release we tried to make it less complicated while keeping all its strength.
That includes a rewrite of the documentation as well as some code changes as listed below:
* Moved Foxx applications to a different folder.
The naming convention now is: <app-path>/_db/<dbname>/<mountpoint>/APP
Before it was: <app-path>/databases/<dbname>/<appname>:<appversion>
This caused some trouble as apps where cached based on name and version and updates did not apply.
Hence the path on filesystem and the app's access URL had no relation to one another.
Now the path on filesystem is identical to the URL (except for slashes and the appended APP)
* Rewrite of Foxx routing
The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback.
This allows us to set the development mode per mountpoint without having to change pathes and hold
apps at seperate locations.
* Foxx Development mode
The development mode used until 2.4 is gone. It has been replaced by a much more mature version.
This includes the deprecation of the javascript.dev-app-path parameter, which is useless since 2.5.
Instead of having two separate app directories for production and development, apps now reside in
one place, which is used for production as well as for development.
Apps can still be put into development mode, changing their behavior compared to production mode.
Development mode apps are still reread from disk at every request, and still they ship more debug
output.
This change has also made the startup options `--javascript.frontend-development-mode` and
`--javascript.dev-app-path` obsolete. The former option will not have any effect when set, and the
latter option is only read and used during the upgrade to 2.5 and does not have any effects later.
* Foxx install process
Installing Foxx apps has been a two step process: import them into ArangoDB and mount them at a
specific mountpoint. These operations have been joined together. You can install an app at one
mountpoint, that's it. No fetch, mount, unmount, purge cycle anymore. The commands have been
simplified to just:
* install: get your Foxx app up and running
* uninstall: shut it down and erase it from disk
* Foxx error output
Until 2.4 the errors produced by Foxx were not optimal. Often, the error message was just
`unable to parse manifest` and contained only an internal stack trace.
In 2.5 we made major improvements there, including a much more finegrained error output that
helps you debug your Foxx apps. The error message printed is now much closer to its source and
should help you track it down.
Also we added the default handlers for unhandled errors in Foxx apps:
* You will get a nice internal error page whenever your Foxx app is called but was not installed
due to any error
* You will get a proper error message when having an uncaught error appears in any app route
In production mode the messages above will NOT contain any information about your Foxx internals
and are safe to be exposed to third party users.
In development mode the messages above will contain the stacktrace (if available), making it easier for
your in-house devs to track down errors in the application.
* added `console` object to Foxx apps. All Foxx apps now have a console object implementing
the familiar Console API in their global scope, which can be used to log diagnostic
messages to the database.
* added `org/arangodb/request` module, which provides a simple API for making HTTP requests
to external services.
* added optimizer rule `propagate-constant-attributes`
This rule will look inside `FILTER` conditions for constant value equality comparisons,
and insert the constant values in other places in `FILTER`s. For example, the rule will
insert `42` instead of `i.value` in the second `FILTER` of the following query:
FOR i IN c1 FOR j IN c2 FILTER i.value == 42 FILTER j.value == i.value RETURN 1
* added `filtered` value to AQL query execution statistics
This value indicates how many documents were filtered by `FilterNode`s in the AQL query.
Note that `IndexRangeNode`s can also filter documents by selecting only the required ranges
from the index. The `filtered` value will not include the work done by `IndexRangeNode`s,
but only the work performed by `FilterNode`s.
* added support for sparse hash and skiplist indexes
Hash and skiplist indexes can optionally be made sparse. Sparse indexes exclude documents
in which at least one of the index attributes is either not set or has a value of `null`.
As such documents are excluded from sparse indexes, they may contain fewer documents than
their non-sparse counterparts. This enables faster indexing and can lead to reduced memory
usage in case the indexed attribute does occur only in some, but not all documents of the
collection. Sparse indexes will also reduce the number of collisions in non-unique hash
indexes in case non-existing or optional attributes are indexed.
In order to create a sparse index, an object with the attribute `sparse` can be added to
the index creation commands:
db.collection.ensureHashIndex(attributeName, { sparse: true });
db.collection.ensureHashIndex(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName1, attributeName2, { sparse: true });
db.collection.ensureSkiplist(attributeName, { sparse: true });
db.collection.ensureSkiplist(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName1, attributeName2, { sparse: true });
Note that in place of the above specialized index creation commands, it is recommended to use
the more general index creation command `ensureIndex`:
```js
db.collection.ensureIndex({ type: "hash", sparse: true, unique: true, fields: [ attributeName ] });
db.collection.ensureIndex({ type: "skiplist", sparse: false, unique: false, fields: [ "a", "b" ] });
```
When not explicitly set, the `sparse` attribute defaults to `false` for new indexes.
This causes a change in behavior when creating a unique hash index without specifying the
sparse flag: in 2.4, unique hash indexes were implicitly sparse, always excluding `null` values.
There was no option to control this behavior, and sparsity was neither supported for non-unique
hash indexes nor skiplists in 2.4. This implicit sparsity of unique hash indexes was considered
an inconsistency, and therefore the behavior was cleaned up in 2.5. As of 2.5, indexes will
only be created sparse if sparsity is explicitly requested. Existing unique hash indexes from 2.4
or before will automatically be migrated so they are still sparse after the upgrade to 2.5.
Geo indexes are implicitly sparse, meaning documents without the indexed location attribute or
containing invalid location coordinate values will be excluded from the index automatically. This
is also a change when compared to pre-2.5 behavior, when documents with missing or invalid
coordinate values may have caused errors on insertion when the geo index' `unique` flag was set
and its `ignoreNull` flag was not.
This was confusing and has been rectified in 2.5. The method `ensureGeoConstaint()` now does the
same as `ensureGeoIndex()`. Furthermore, the attributes `constraint`, `unique`, `ignoreNull` and
`sparse` flags are now completely ignored when creating geo indexes.
The same is true for fulltext indexes. There is no need to specify non-uniqueness or sparsity for
geo or fulltext indexes. They will always be non-unique and sparse.
As sparse indexes may exclude some documents, they cannot be used for every type of query.
Sparse hash indexes cannot be used to find documents for which at least one of the indexed
attributes has a value of `null`. For example, the following AQL query cannot use a sparse
index, even if one was created on attribute `attr`:
FOR doc In collection
FILTER doc.attr == null
RETURN doc
If the lookup value is non-constant, a sparse index may or may not be used, depending on
the other types of conditions in the query. If the optimizer can safely determine that
the lookup value cannot be `null`, a sparse index may be used. When uncertain, the optimizer
will not make use of a sparse index in a query in order to produce correct results.
For example, the following queries cannot use a sparse index on `attr` because the optimizer
will not know beforehand whether the comparsion values for `doc.attr` will include `null`:
FOR doc In collection
FILTER doc.attr == SOME_FUNCTION(...)
RETURN doc
FOR other IN otherCollection
FOR doc In collection
FILTER doc.attr == other.attr
RETURN doc
Sparse skiplist indexes can be used for sorting if the optimizer can safely detect that the
index range does not include `null` for any of the index attributes.
* inspection of AQL data-modification queries will now detect if the data-modification part
of the query can run in lockstep with the data retrieval part of the query, or if the data
retrieval part must be executed before the data modification can start.
Executing the two in lockstep allows using much smaller buffers for intermediate results
and starts the actual data-modification operations much earlier than if the two phases
were executed seperately.
* Allow dynamic attribute names in AQL object literals
This allows using arbitrary expressions to construct attribute names in object
literals specified in AQL queries. To disambiguate expressions and other unquoted
attribute names, dynamic attribute names need to be enclosed in brackets (`[` and `]`).
Example:
FOR i IN 1..100
RETURN { [ CONCAT('value-of-', i) ] : i }
* make AQL optimizer rule "use-index-for-sort" remove sort also in case a non-sorted
index (e.g. a hash index) is used for only equality lookups and all sort attributes
are covered by the index.
Example that does not require an extra sort (needs hash index on `value`):
FOR doc IN collection FILTER doc.value == 1 SORT doc.value RETURN doc
Another example that does not require an extra sort (with hash index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 && doc.value2 == 2 SORT doc.value1, doc.value2 RETURN doc
* make AQL optimizer rule "use-index-for-sort" remove sort also in case the sort critieria
excludes the left-most index attributes, but the left-most index attributes are used
by the index for equality-only lookups.
Example that can use the index for sorting (needs skiplist index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 SORT doc.value2 RETURN doc
* added selectivity estimates for primary index, edge index, and hash index
The selectivity estimates are returned by the `GET /_api/index` REST API method
in a sub-attribute `selectivityEstimate` for each index that supports it. This
attribute will be omitted for indexes that do not provide selectivity estimates.
If provided, the selectivity estimate will be a numeric value between 0 and 1.
Selectivity estimates will also be reported in the result of `collection.getIndexes()`
for all indexes that support this. If no selectivity estimate can be determined for
an index, the attribute `selectivityEstimate` will be omitted here, too.
The web interface also shows selectivity estimates for each index that supports this.
Currently the following index types can provide selectivity estimates:
- primary index
- edge index
- hash index (unique and non-unique)
No selectivity estimates will be provided when running in cluster mode.
* fixed issue #1226: arangod log issues
* added additional logger if arangod is started in foreground mode on a tty
* added AQL optimizer rule "move-calculations-down"
* use exclusive native SRWLocks on Windows instead of native mutexes
* added AQL functions MD5, SHA1, and RANDOM_TOKEN.
* reduced number of string allocations when parsing certain AQL queries
parsing numbers (integers or doubles) does not require a string allocation
per number anymore
* RequestContext#bodyParam now accepts arbitrary joi schemas and rejects invalid (but well-formed) request bodies.
* enforce that AQL user functions are wrapped inside JavaScript function () declarations
AQL user functions were always expected to be wrapped inside a JavaScript function, but previously
this was not enforced when registering a user function. Enforcing the AQL user functions to be contained
inside functions prevents functions from doing some unexpected things that may have led to undefined
behavior.
* Windows service uninstalling: only remove service if it points to the currently running binary,
or --force was specified.
* Windows (debug only): print stacktraces on crash and run minidump
* Windows (cygwin): if you run arangosh in a cygwin shell or via ssh we will detect this and use
the appropriate output functions.
* Windows: improve process management
* fix ipv6 reverse ip lookups - so far we only did ipv4 addresses.
* improve join documentation, add outer join example
* run jslint for unit tests too, to prevent "memory leaks" by global js objects with native code.
* fix error logging for exceptions - we wouldn't log the exception message itself so far.
* improve error reporting in the http client (windows & *nix)
* improve error reports in cluster
* Standard Errors can now contain custom messages.
-- ArangoDB Maintainer <info@arangodb.org> Tue, 24 Feb 2015 23:30:19 +0100
arangodb (2.5.0b1-1.1) stable; urgency=low
* Changed to Version 2.5.0-beta1
* front-end: dashboard tries not to (re)load statistics if user has no access
* V8: Upgrade to version 3.31.74.1
* etcd: Upgrade to version 2.0 - This requires go 1.3 to compile at least.
* refuse to startup if ICU wasn't initialized, this will i.e. prevent errors from being printed,
and libraries from being loaded.
* front-end: unwanted removal of index table header after creating new index
* fixed issue #1248: chrome: applications filtering not working
* fixed issue #1198: queries remain in aql editor (front-end) if you navigate through different tabs
* Simplify usage of Foxx
Thanks to our user feedback we learned that Foxx is a powerful, yet rather complicated concept.
With this release we tried to make it less complicated while keeping all its strength.
That includes a rewrite of the documentation as well as some code changes as listed below:
* Moved Foxx applications to a different folder.
The naming convention now is: <app-path>/_db/<dbname>/<mointpoint>/APP
Before it was: <app-path>/databases/<dbname>/<appname>:<appversion>
This caused some trouble as apps where cached based on name and version and updates did not apply.
Hence the path on filesystem and the app's access URL had no relation to one another.
Now the path on filesystem is identical to the URL (except for slashes and the appended APP)
* Rewrite of Foxx routing
The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback.
This allows us to set the development mode per mountpoint without having to change pathes and hold
apps at seperate locations.
* Foxx Development mode
The development mode used until 2.4 is gone. It has been replaced by a much more mature version.
This includes the deprecation of the javascript.dev-app-path parameter, which is useless since 2.5.
Instead of having two separate app directories for production and development, apps now reside in
one place, which is used for production as well as for development.
Apps can still be put into development mode, changing their behavior compared to production mode.
Development mode apps are still reread from disk at every request, and still they ship more debug
output.
This change has also made the startup options `--javascript.frontend-development-mode` and
`--javascript.dev-app-path` obsolete. The former option will not have any effect when set, and the
latter option is only read and used during the upgrade to 2.5 and does not have any effects later.
* Foxx install process
Installing Foxx apps has been a two step process: import them into ArangoDB and mount them at a
specific mountpoint. These operations have been joined together. You can install an app at one
mountpoint, that's it. No fetch, mount, unmount, purge cycle anymore. The commands have been
simplified to just:
* install: get your Foxx app up and running
* uninstall: shut it down and erase it from disk
* Foxx error output
Until 2.4 the errors produced by Foxx were not optimal. Often, the error message was just
`unable to parse manifest` and contained only an internal stack trace.
In 2.5 we made major improvements there, including a much more finegrained error output that
helps you debug your Foxx apps. The error message printed is now much closer to its source and
should help you track it down.
Also we added the default handlers for unhandled errors in Foxx apps:
* You will get a nice internal error page whenever your Foxx app is called but was not installed
due to any error
* You will get a proper error message when having an uncaught error appears in any app route
In production mode the messages above will NOT contain any information about your Foxx internals
and are safe to be exposed to third party users.
In development mode the messages above will contain the stacktrace (if available), making it easier for
your in-house devs to track down errors in the application.
* added `console` object to Foxx apps. All Foxx apps now have a console object implementing
the familiar Console API in their global scope, which can be used to log diagnostic
messages to the database.
* added `org/arangodb/request` module, which provides a simple API for making HTTP requests
to external services.
* added optimizer rule `propagate-constant-attributes`
This rule will look inside `FILTER` conditions for constant value equality comparisons,
and insert the constant values in other places in `FILTER`s. For example, the rule will
insert `42` instead of `i.value` in the second `FILTER` of the following query:
FOR i IN c1 FOR j IN c2 FILTER i.value == 42 FILTER j.value == i.value RETURN 1
* added `filtered` value to AQL query execution statistics
This value indicates how many documents were filtered by `FilterNode`s in the AQL query.
Note that `IndexRangeNode`s can also filter documents by selecting only the required ranges
from the index. The `filtered` value will not include the work done by `IndexRangeNode`s,
but only the work performed by `FilterNode`s.
* added support for sparse hash and skiplist indexes
Hash and skiplist indexes can optionally be made sparse. Sparse indexes exclude documents
in which at least one of the index attributes is either not set or has a value of `null`.
As such documents are excluded from sparse indexes, they may contain fewer documents than
their non-sparse counterparts. This enables faster indexing and can lead to reduced memory
usage in case the indexed attribute does occur only in some, but not all documents of the
collection. Sparse indexes will also reduce the number of collisions in non-unique hash
indexes in case non-existing or optional attributes are indexed.
In order to create a sparse index, an object with the attribute `sparse` can be added to
the index creation commands:
db.collection.ensureHashIndex(attributeName, { sparse: true });
db.collection.ensureHashIndex(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName1, attributeName2, { sparse: true });
db.collection.ensureSkiplist(attributeName, { sparse: true });
db.collection.ensureSkiplist(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName1, attributeName2, { sparse: true });
Note that in place of the above specialized index creation commands, it is recommended to use
the more general index creation command `ensureIndex`:
```js
db.collection.ensureIndex({ type: "hash", sparse: true, unique: true, fields: [ attributeName ] });
db.collection.ensureIndex({ type: "skiplist", sparse: false, unique: false, fields: [ "a", "b" ] });
```
When not explicitly set, the `sparse` attribute defaults to `false` for new indexes.
This causes a change in behavior when creating a unique hash index without specifying the
sparse flag: in 2.4, unique hash indexes were implicitly sparse, always excluding `null` values.
There was no option to control this behavior, and sparsity was neither supported for non-unique
hash indexes nor skiplists in 2.4. This implicit sparsity of unique hash indexes was considered
an inconsistency, and therefore the behavior was cleaned up in 2.5. As of 2.5, indexes will
only be created sparse if sparsity is explicitly requested. Existing unique hash indexes from 2.4
or before will automatically be migrated so they are still sparse after the upgrade to 2.5.
Geo indexes are implicitly sparse, meaning documents without the indexed location attribute or
containing invalid location coordinate values will be excluded from the index automatically. This
is also a change when compared to pre-2.5 behavior, when documents with missing or invalid
coordinate values may have caused errors on insertion when the geo index' `unique` flag was set
and its `ignoreNull` flag was not.
This was confusing and has been rectified in 2.5. The method `ensureGeoConstaint()` now does the
same as `ensureGeoIndex()`. Furthermore, the attributes `constraint`, `unique`, `ignoreNull` and
`sparse` flags are now completely ignored when creating geo indexes.
The same is true for fulltext indexes. There is no need to specify non-uniqueness or sparsity for
geo or fulltext indexes. They will always be non-unique and sparse.
As sparse indexes may exclude some documents, they cannot be used for every type of query.
Sparse hash indexes cannot be used to find documents for which at least one of the indexed
attributes has a value of `null`. For example, the following AQL query cannot use a sparse
index, even if one was created on attribute `attr`:
FOR doc In collection
FILTER doc.attr == null
RETURN doc
If the lookup value is non-constant, a sparse index may or may not be used, depending on
the other types of conditions in the query. If the optimizer can safely determine that
the lookup value cannot be `null`, a sparse index may be used. When uncertain, the optimizer
will not make use of a sparse index in a query in order to produce correct results.
For example, the following queries cannot use a sparse index on `attr` because the optimizer
will not know beforehand whether the comparsion values for `doc.attr` will include `null`:
FOR doc In collection
FILTER doc.attr == SOME_FUNCTION(...)
RETURN doc
FOR other IN otherCollection
FOR doc In collection
FILTER doc.attr == other.attr
RETURN doc
Sparse skiplist indexes can be used for sorting if the optimizer can safely detect that the
index range does not include `null` for any of the index attributes.
* inspection of AQL data-modification queries will now detect if the data-modification part
of the query can run in lockstep with the data retrieval part of the query, or if the data
retrieval part must be executed before the data modification can start.
Executing the two in lockstep allows using much smaller buffers for intermediate results
and starts the actual data-modification operations much earlier than if the two phases
were executed seperately.
* Allow dynamic attribute names in AQL object literals
This allows using arbitrary expressions to construct attribute names in object
literals specified in AQL queries. To disambiguate expressions and other unquoted
attribute names, dynamic attribute names need to be enclosed in brackets (`[` and `]`).
Example:
FOR i IN 1..100
RETURN { [ CONCAT('value-of-', i) ] : i }
* make AQL optimizer rule "use-index-for-sort" remove sort also in case a non-sorted
index (e.g. a hash index) is used for only equality lookups and all sort attributes
are covered by the index.
Example that does not require an extra sort (needs hash index on `value`):
FOR doc IN collection FILTER doc.value == 1 SORT doc.value RETURN doc
Another example that does not require an extra sort (with hash index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 && doc.value2 == 2 SORT doc.value1, doc.value2 RETURN doc
* make AQL optimizer rule "use-index-for-sort" remove sort also in case the sort critieria
excludes the left-most index attributes, but the left-most index attributes are used
by the index for equality-only lookups.
Example that can use the index for sorting (needs skiplist index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 SORT doc.value2 RETURN doc
* added selectivity estimates for primary index, edge index, and hash index
The selectivity estimates are returned by the `GET /_api/index` REST API method
in a sub-attribute `selectivityEstimate` for each index that supports it. This
attribute will be omitted for indexes that do not provide selectivity estimates.
If provided, the selectivity estimate will be a numeric value between 0 and 1.
Selectivity estimates will also be reported in the result of `collection.getIndexes()`
for all indexes that support this. If no selectivity estimate can be determined for
an index, the attribute `selectivityEstimate` will be omitted here, too.
The web interface also shows selectivity estimates for each index that supports this.
Currently the following index types can provide selectivity estimates:
- primary index
- edge index
- hash index (unique and non-unique)
No selectivity estimates will be provided when running in cluster mode.
* fixed issue #1226: arangod log issues
* added additional logger if arangod is started in foreground mode on a tty
* added AQL optimizer rule "move-calculations-down"
* use exclusive native SRWLocks on Windows instead of native mutexes
* added AQL functions MD5, SHA1, and RANDOM_TOKEN.
* reduced number of string allocations when parsing certain AQL queries
parsing numbers (integers or doubles) does not require a string allocation
per number anymore
* RequestContext#bodyParam now accepts arbitrary joi schemas and rejects invalid (but well-formed) request bodies.
* enforce that AQL user functions are wrapped inside JavaScript function () declarations
AQL user functions were always expected to be wrapped inside a JavaScript function, but previously
this was not enforced when registering a user function. Enforcing the AQL user functions to be contained
inside functions prevents functions from doing some unexpected things that may have led to undefined
behavior.
* Windows service uninstalling: only remove service if it points to the currently running binary,
or --force was specified.
* Windows (debug only): print stacktraces on crash and run minidump
* Windows (cygwin): if you run arangosh in a cygwin shell or via ssh we will detect this and use
the appropriate output functions.
* Windows: improve process management
* fix ipv6 reverse ip lookups - so far we only did ipv4 addresses.
* improve join documentation, add outer join example
* run jslint for unit tests too, to prevent "memory leaks" by global js objects with native code.
* fix error logging for exceptions - we wouldn't log the exception message itself so far.
* improve error reporting in the http client (windows & *nix)
* improve error reports in cluster
* Standard Errors can now contain custom messages.
-- ArangoDB Maintainer <info@arangodb.org> Mon, 23 Feb 2015 16:19:21 +0100
arangodb (2.5.0a8-1.1) stable; urgency=low
* Changed to Version 2.5.0-alpha8
* front-end: dashboard tries not to (re)load statistics if user has no access
* V8: Upgrade to version 3.31.74.1
* etcd: Upgrade to version 2.0 - This requires go 1.3 to compile at least.
* refuse to startup if ICU wasn't initialized, this will i.e. prevent errors from being printed,
and libraries from being loaded.
* front-end: unwanted removal of index table header after creating new index
* fixed issue #1248: chrome: applications filtering not working
* fixed issue #1198: queries remain in aql editor (front-end) if you navigate through different tabs
* Simplify usage of Foxx
Thanks to our user feedback we learned that Foxx is a powerful, yet rather complicated concept.
With this release we tried to make it less complicated while keeping all its strength.
That includes a rewrite of the documentation as well as some code changes as listed below:
* Moved Foxx applications to a different folder.
The naming convention now is: <app-path>/_db/<dbname>/<mointpoint>/APP
Before it was: <app-path>/databases/<dbname>/<appname>:<appversion>
This caused some trouble as apps where cached based on name and version and updates did not apply.
Hence the path on filesystem and the app's access URL had no relation to one another.
Now the path on filesystem is identical to the URL (except for slashes and the appended APP)
* Rewrite of Foxx routing
The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback.
This allows us to set the development mode per mountpoint without having to change pathes and hold
apps at seperate locations.
* Foxx Development mode
The development mode used until 2.4 is gone. It has been replaced by a much more mature version.
This includes the deprecation of the javascript.dev-app-path parameter, which is useless since 2.5.
Instead of having two separate app directories for production and development, apps now reside in
one place, which is used for production as well as for development.
Apps can still be put into development mode, changing their behavior compared to production mode.
Development mode apps are still reread from disk at every request, and still they ship more debug
output.
This change has also made the startup options `--javascript.frontend-development-mode` and
`--javascript.dev-app-path` obsolete. The former option will not have any effect when set, and the
latter option is only read and used during the upgrade to 2.5 and does not have any effects later.
* Foxx install process
Installing Foxx apps has been a two step process: import them into ArangoDB and mount them at a
specific mountpoint. These operations have been joined together. You can install an app at one
mountpoint, that's it. No fetch, mount, unmount, purge cycle anymore. The commands have been
simplified to just:
* install: get your Foxx app up and running
* uninstall: shut it down and erase it from disk
* Foxx error output
Until 2.4 the errors produced by Foxx were not optimal. Often, the error message was just
`unable to parse manifest` and contained only an internal stack trace.
In 2.5 we made major improvements there, including a much more finegrained error output that
helps you debug your Foxx apps. The error message printed is now much closer to its source and
should help you track it down.
Also we added the default handlers for unhandled errors in Foxx apps:
* You will get a nice internal error page whenever your Foxx app is called but was not installed
due to any error
* You will get a proper error message when having an uncaught error appears in any app route
In production mode the messages above will NOT contain any information about your Foxx internals
and are safe to be exposed to third party users.
In development mode the messages above will contain the stacktrace (if available), making it easier for
your in-house devs to track down errors in the application.
* added `console` object to Foxx apps. All Foxx apps now have a console object implementing
the familiar Console API in their global scope, which can be used to log diagnostic
messages to the database.
* added `org/arangodb/request` module, which provides a simple API for making HTTP requests
to external services.
* added optimizer rule `propagate-constant-attributes`
This rule will look inside `FILTER` conditions for constant value equality comparisons,
and insert the constant values in other places in `FILTER`s. For example, the rule will
insert `42` instead of `i.value` in the second `FILTER` of the following query:
FOR i IN c1 FOR j IN c2 FILTER i.value == 42 FILTER j.value == i.value RETURN 1
* added `filtered` value to AQL query execution statistics
This value indicates how many documents were filtered by `FilterNode`s in the AQL query.
Note that `IndexRangeNode`s can also filter documents by selecting only the required ranges
from the index. The `filtered` value will not include the work done by `IndexRangeNode`s,
but only the work performed by `FilterNode`s.
* added support for sparse hash and skiplist indexes
Hash and skiplist indexes can optionally be made sparse. Sparse indexes exclude documents
in which at least one of the index attributes is either not set or has a value of `null`.
As such documents are excluded from sparse indexes, they may contain fewer documents than
their non-sparse counterparts. This enables faster indexing and can lead to reduced memory
usage in case the indexed attribute does occur only in some, but not all documents of the
collection. Sparse indexes will also reduce the number of collisions in non-unique hash
indexes in case non-existing or optional attributes are indexed.
In order to create a sparse index, an object with the attribute `sparse` can be added to
the index creation commands:
db.collection.ensureHashIndex(attributeName, { sparse: true });
db.collection.ensureHashIndex(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName1, attributeName2, { sparse: true });
db.collection.ensureSkiplist(attributeName, { sparse: true });
db.collection.ensureSkiplist(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName1, attributeName2, { sparse: true });
Note that in place of the above specialized index creation commands, it is recommended to use
the more general index creation command `ensureIndex`:
```js
db.collection.ensureIndex({ type: "hash", sparse: true, unique: true, fields: [ attributeName ] });
db.collection.ensureIndex({ type: "skiplist", sparse: false, unique: false, fields: [ "a", "b" ] });
```
When not explicitly set, the `sparse` attribute defaults to `false` for new indexes.
This causes a change in behavior when creating a unique hash index without specifying the
sparse flag: in 2.4, unique hash indexes were implicitly sparse, always excluding `null` values.
There was no option to control this behavior, and sparsity was neither supported for non-unique
hash indexes nor skiplists in 2.4. This implicit sparsity of unique hash indexes was considered
an inconsistency, and therefore the behavior was cleaned up in 2.5. As of 2.5, indexes will
only be created sparse if sparsity is explicitly requested. Existing unique hash indexes from 2.4
or before will automatically be migrated so they are still sparse after the upgrade to 2.5.
Geo indexes are implicitly sparse, meaning documents without the indexed location attribute or
containing invalid location coordinate values will be excluded from the index automatically. This
is also a change when compared to pre-2.5 behavior, when documents with missing or invalid
coordinate values may have caused errors on insertion when the geo index' `unique` flag was set
and its `ignoreNull` flag was not.
This was confusing and has been rectified in 2.5. The method `ensureGeoConstaint()` now does the
same as `ensureGeoIndex()`. Furthermore, the attributes `constraint`, `unique`, `ignoreNull` and
`sparse` flags are now completely ignored when creating geo indexes.
The same is true for fulltext indexes. There is no need to specify non-uniqueness or sparsity for
geo or fulltext indexes. They will always be non-unique and sparse.
As sparse indexes may exclude some documents, they cannot be used for every type of query.
Sparse hash indexes cannot be used to find documents for which at least one of the indexed
attributes has a value of `null`. For example, the following AQL query cannot use a sparse
index, even if one was created on attribute `attr`:
FOR doc In collection
FILTER doc.attr == null
RETURN doc
If the lookup value is non-constant, a sparse index may or may not be used, depending on
the other types of conditions in the query. If the optimizer can safely determine that
the lookup value cannot be `null`, a sparse index may be used. When uncertain, the optimizer
will not make use of a sparse index in a query in order to produce correct results.
For example, the following queries cannot use a sparse index on `attr` because the optimizer
will not know beforehand whether the comparsion values for `doc.attr` will include `null`:
FOR doc In collection
FILTER doc.attr == SOME_FUNCTION(...)
RETURN doc
FOR other IN otherCollection
FOR doc In collection
FILTER doc.attr == other.attr
RETURN doc
Sparse skiplist indexes can be used for sorting if the optimizer can safely detect that the
index range does not include `null` for any of the index attributes.
* inspection of AQL data-modification queries will now detect if the data-modification part
of the query can run in lockstep with the data retrieval part of the query, or if the data
retrieval part must be executed before the data modification can start.
Executing the two in lockstep allows using much smaller buffers for intermediate results
and starts the actual data-modification operations much earlier than if the two phases
were executed seperately.
* Allow dynamic attribute names in AQL object literals
This allows using arbitrary expressions to construct attribute names in object
literals specified in AQL queries. To disambiguate expressions and other unquoted
attribute names, dynamic attribute names need to be enclosed in brackets (`[` and `]`).
Example:
FOR i IN 1..100
RETURN { [ CONCAT('value-of-', i) ] : i }
* make AQL optimizer rule "use-index-for-sort" remove sort also in case a non-sorted
index (e.g. a hash index) is used for only equality lookups and all sort attributes
are covered by the index.
Example that does not require an extra sort (needs hash index on `value`):
FOR doc IN collection FILTER doc.value == 1 SORT doc.value RETURN doc
Another example that does not require an extra sort (with hash index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 && doc.value2 == 2 SORT doc.value1, doc.value2 RETURN doc
* make AQL optimizer rule "use-index-for-sort" remove sort also in case the sort critieria
excludes the left-most index attributes, but the left-most index attributes are used
by the index for equality-only lookups.
Example that can use the index for sorting (needs skiplist index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 SORT doc.value2 RETURN doc
* added selectivity estimates for primary index, edge index, and hash index
The selectivity estimates are returned by the `GET /_api/index` REST API method
in a sub-attribute `selectivityEstimate` for each index that supports it. This
attribute will be omitted for indexes that do not provide selectivity estimates.
If provided, the selectivity estimate will be a numeric value between 0 and 1.
Selectivity estimates will also be reported in the result of `collection.getIndexes()`
for all indexes that support this. If no selectivity estimate can be determined for
an index, the attribute `selectivityEstimate` will be omitted here, too.
The web interface also shows selectivity estimates for each index that supports this.
Currently the following index types can provide selectivity estimates:
- primary index
- edge index
- hash index (unique and non-unique)
No selectivity estimates will be provided when running in cluster mode.
* fixed issue #1226: arangod log issues
* added additional logger if arangod is started in foreground mode on a tty
* added AQL optimizer rule "move-calculations-down"
* use exclusive native SRWLocks on Windows instead of native mutexes
* added AQL functions MD5, SHA1, and RANDOM_TOKEN.
* reduced number of string allocations when parsing certain AQL queries
parsing numbers (integers or doubles) does not require a string allocation
per number anymore
* RequestContext#bodyParam now accepts arbitrary joi schemas and rejects invalid (but well-formed) request bodies.
* enforce that AQL user functions are wrapped inside JavaScript function () declarations
AQL user functions were always expected to be wrapped inside a JavaScript function, but previously
this was not enforced when registering a user function. Enforcing the AQL user functions to be contained
inside functions prevents functions from doing some unexpected things that may have led to undefined
behavior.
* Windows service uninstalling: only remove service if it points to the currently running binary,
or --force was specified.
* Windows (debug only): print stacktraces on crash and run minidump
* Windows (cygwin): if you run arangosh in a cygwin shell or via ssh we will detect this and use
the appropriate output functions.
* Windows: improve process management
* fix ipv6 reverse ip lookups - so far we only did ipv4 addresses.
* improve join documentation, add outer join example
* run jslint for unit tests too, to prevent "memory leaks" by global js objects with native code.
* fix error logging for exceptions - we wouldn't log the exception message itself so far.
* improve error reporting in the http client (windows & *nix)
* improve error reports in cluster
* Standard Errors can now contain custom messages.
-- ArangoDB Maintainer <info@arangodb.org> Fri, 20 Feb 2015 14:16:23 +0100
arangodb (2.5.0a4-1.1) stable; urgency=low
* Changed to Version 2.5.0-alpha4
* front-end: unwanted removal of index table header after creating new index
* fixed issue #1248: chrome: applications filtering not working
* fixed issue #1198: queries remain in aql editor (front-end) if you navigate through different tabs
* Simplify usage of Foxx
Thanks to our user feedback we learned that Foxx is a powerful, yet rather complicated concept.
With this release we tried to make it less complicated while keeping all its strength.
That includes a rewrite of the documentation as well as some code changes as listed below:
* Moved Foxx applications to a different folder.
The naming convention now is: <app-path>/_db/<dbname>/<mointpoint>/APP
Before it was: <app-path>/databases/<dbname>/<appname>:<appversion>
This caused some trouble as apps where cached based on name and version and updates did not apply.
Hence the path on filesystem and the app's access URL had no relation to one another.
Now the path on filesystem is identical to the URL (except for slashes and the appended APP)
* Rewrite of Foxx routing
The routing of Foxx has been exposed to major internal changes we adjusted because of user feedback.
This allows us to set the development mode per mountpoint without having to change pathes and hold
apps at seperate locations.
* Foxx Development mode
The development mode used until 2.4 is gone. It has been replaced by a much more mature version.
This includes the deprecation of the javascript.dev-app-path parameter, which is useless since 2.5.
Instead of having two separate app directories for production and development, apps now reside in
one place, which is used for production as well as for development.
Apps can still be put into development mode, changing their behavior compared to production mode.
Development mode apps are still reread from disk at every request, and still they ship more debug
output.
* Foxx install process
Installing Foxx apps has been a two step process: import them into ArangoDB and mount them at a
specific mountpoint. These operations have been joined together. You can install an app at one
mountpoint, that's it. No fetch, mount, unmount, purge cycle anymore. The commands have been
simplified to just:
* install: get your Foxx app up and running
* uninstall: shut it down and erase it from disk
* Foxx error output
Until 2.4 the errors produced by Foxx were not optimal. Often, the error message was just
`unable to parse manifest` and contained only an internal stack trace.
In 2.5 we made major improvements there, including a much more finegrained error output that
helps you debug your Foxx apps. The error message printed is now much closer to its source and
should help you track it down.
Also we added the default handlers for unhandled errors in Foxx apps:
* You will get a nice internal error page whenever your Foxx app is called but was not installed
due to any error
* You will get a proper error message when having an uncaught error appears in any app route
In production mode the messages above will NOT contain any information about your Foxx internals
and are safe to be exposed to third party users.
In development mode the messages above will contain the stacktrace (if available), making it easier for
your in-house devs to track down errors in the application.
* added `console` object to Foxx apps. All Foxx apps now have a console object implementing
the familiar Console API in their global scope, which can be used to log diagnostic
messages to the database.
* added `org/arangodb/request` module, which provides a simple API for making HTTP requests
to external services.
* added optimizer rule `propagate-constant-attributes`
This rule will look inside `FILTER` conditions for constant value equality comparisons,
and insert the constant values in other places in `FILTER`s. For example, the rule will
insert `42` instead of `i.value` in the second `FILTER` of the following query:
FOR i IN c1 FOR j IN c2 FILTER i.value == 42 FILTER j.value == i.value RETURN 1
* added `filtered` value to AQL query execution statistics
This value indicates how many documents were filtered by `FilterNode`s in the AQL query.
Note that `IndexRangeNode`s can also filter documents by selecting only the required ranges
from the index. The `filtered` value will not include the work done by `IndexRangeNode`s,
but only the work performed by `FilterNode`s.
* added support for sparse hash and skiplist indexes
Hash and skiplist indexes can optionally be made sparse. Sparse indexes exclude documents
in which at least one of the index attributes is either not set or has a value of `null`.
As such documents are excluded from sparse indexes, they may contain fewer documents than
their non-sparse counterparts. This enables faster indexing and can lead to reduced memory
usage in case the indexed attribute does occur only in some, but not all documents of the
collection. Sparse indexes will also reduce the number of collisions in non-unique hash
indexes in case non-existing or optional attributes are indexed.
In order to create a sparse index, an object with the attribute `sparse` can be added to
the index creation commands:
db.collection.ensureHashIndex(attributeName, { sparse: true });
db.collection.ensureHashIndex(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName1, attributeName2, { sparse: true });
db.collection.ensureSkiplist(attributeName, { sparse: true });
db.collection.ensureSkiplist(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName1, attributeName2, { sparse: true });
When not explicitly set, the `sparse` attribute defaults to `false` for new indexes.
This causes a change in behavior when creating a unique hash index without specifying the
sparse flag: in 2.4, unique hash indexes were implicitly sparse, always excluding `null` values.
There was no option to control this behavior, and sparsity was neither supported for non-unique
hash indexes nor skiplists in 2.4. This implicit sparsity of unique hash indexes was considered
an inconsistency, and therefore the behavior was cleaned up in 2.5. As of 2.5, indexes will
only be created sparse if sparsity is explicitly requested. Existing unique hash indexes from 2.4
or before will automatically be migrated so they are still sparse after the upgrade to 2.5.
Indexes other than hash and skiplist do not support sparsity.
As sparse indexes may exclude some documents, they cannot be used for every type of query.
Sparse hash indexes cannot be used to find documents for which at least one of the indexed
attributes has a value of `null`. For example, the following AQL query cannot use a sparse
index, even if one was created on attribute `attr`:
FOR doc In collection
FILTER doc.attr == null
RETURN doc
If the lookup value is non-constant, a sparse index may or may not be used, depending on
the other types of conditions in the query. If the optimizer can safely determine that
the lookup value cannot be `null`, a sparse index may be used. When uncertain, the optimizer
will not make use of a sparse index in a query in order to produce correct results.
For example, the following queries cannot use a sparse index on `attr` because the optimizer
will not know beforehand whether the comparsion values for `doc.attr` will include `null`:
FOR doc In collection
FILTER doc.attr == SOME_FUNCTION(...)
RETURN doc
FOR other IN otherCollection
FOR doc In collection
FILTER doc.attr == other.attr
RETURN doc
Sparse skiplist indexes can be used for sorting if the optimizer can safely detect that the
index range does not include `null` for any of the index attributes.
* inspection of AQL data-modification queries will now detect if the data-modification part
of the query can run in lockstep with the data retrieval part of the query, or if the data
retrieval part must be executed before the data modification can start.
Executing the two in lockstep allows using much smaller buffers for intermediate results
and starts the actual data-modification operations much earlier than if the two phases
were executed seperately.
* Allow dynamic attribute names in AQL object literals
This allows using arbitrary expressions to construct attribute names in object
literals specified in AQL queries. To disambiguate expressions and other unquoted
attribute names, dynamic attribute names need to be enclosed in brackets (`[` and `]`).
Example:
FOR i IN 1..100
RETURN { [ CONCAT('value-of-', i) ] : i }
* make AQL optimizer rule "use-index-for-sort" remove sort also in case a non-sorted
index (e.g. a hash index) is used for only equality lookups and all sort attributes
are covered by the index.
Example that does not require an extra sort (needs hash index on `value`):
FOR doc IN collection FILTER doc.value == 1 SORT doc.value RETURN doc
Another example that does not require an extra sort (with hash index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 && doc.value2 == 2 SORT doc.value1, doc.value2 RETURN doc
* make AQL optimizer rule "use-index-for-sort" remove sort also in case the sort critieria
excludes the left-most index attributes, but the left-most index attributes are used
by the index for equality-only lookups.
Example that can use the index for sorting (needs skiplist index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 SORT doc.value2 RETURN doc
* added selectivity estimates for primary index, edge index, and hash index
The selectivity estimates are returned by the `GET /_api/index` REST API method
in a sub-attribute `selectivityEstimate` for each index that supports it. This
attribute will be omitted for indexes that do not provide selectivity estimates.
If provided, the selectivity estimate will be a numeric value between 0 and 1.
Selectivity estimates will also be reported in the result of `collection.getIndexes()`
for all indexes that support this. If no selectivity estimate can be determined for
an index, the attribute `selectivityEstimate` will be omitted here, too.
The web interface also shows selectivity estimates for each index that supports this.
Currently the following index types can provide selectivity estimates:
- primary index
- edge index
- hash index (unique and non-unique)
No selectivity estimates will be provided when running in cluster mode.
* fixed issue #1226: arangod log issues
* added additional logger if arangod is started in foreground mode on a tty
* added AQL optimizer rule "move-calculations-down"
* use exclusive native SRWLocks on Windows instead of native mutexes
* added AQL functions MD5, SHA1, and RANDOM_TOKEN.
* reduced number of string allocations when parsing certain AQL queries
parsing numbers (integers or doubles) does not require a string allocation
per number anymore
* RequestContext#bodyParam now accepts arbitrary joi schemas and rejects invalid (but well-formed) request bodies.
* enforce that AQL user functions are wrapped inside JavaScript function () declarations
AQL user functions were always expected to be wrapped inside a JavaScript function, but previously
this was not enforced when registering a user function. Enforcing the AQL user functions to be contained
inside functions prevents functions from doing some unexpected things that may have led to undefined
behavior.
-- ArangoDB Maintainer <info@arangodb.org> Tue, 17 Feb 2015 21:16:18 +0100
arangodb (2.5.0a3-1.1) stable; urgency=low
* Changed to Version 2.5.0-alpha3
* added optimizer rule `propagate-constant-attributes`
This rule will look inside `FILTER` conditions for constant value equality comparisons,
and insert the constant values in other places in `FILTER`s. For example, the rule will
insert `42` instead of `i.value` in the second `FILTER` of the following query:
FOR i IN c1 FOR j IN c2 FILTER i.value == 42 FILTER j.value == i.value RETURN 1
* added `filtered` value to AQL query execution statistics
This value indicates how many documents were filtered by `FilterNode`s in the AQL query.
Note that `IndexRangeNode`s can also filter documents by selecting only the required ranges
from the index. The `filtered` value will not include the work done by `IndexRangeNode`s,
but only the work performed by `FilterNode`s.
* added support for sparse hash and skiplist indexes
Hash and skiplist indexes can optionally be made sparse. Sparse indexes exclude documents
in which at least one of the index attributes is either not set or has a value of `null`.
As such documents are excluded from sparse indexes, they may contain fewer documents than
their non-sparse counterparts. This enables faster indexing and can lead to reduced memory
usage in case the indexed attribute does occur only in some, but not all documents of the
collection. Sparse indexes will also reduce the number of collisions in non-unique hash
indexes in case non-existing or optional attributes are indexed.
In order to create a sparse index, an object with the attribute `sparse` can be added to
the index creation commands:
db.collection.ensureHashIndex(attributeName, { sparse: true });
db.collection.ensureHashIndex(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName, { sparse: true });
db.collection.ensureUniqueConstraint(attributeName1, attributeName2, { sparse: true });
db.collection.ensureSkiplist(attributeName, { sparse: true });
db.collection.ensureSkiplist(attributeName1, attributeName2, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName, { sparse: true });
db.collection.ensureUniqueSkiplist(attributeName1, attributeName2, { sparse: true });
When not explicitly set, the `sparse` attribute defaults to `false` for new indexes.
Other indexes than hash and skiplist do not support sparsity.
As sparse indexes may exclude some documents from the collection, they cannot be used for
all types of queries. Sparse hash indexes cannot be used to find documents for which at
least one of the indexed attributes has a value of `null`. For example, the following AQL
query cannot use a sparse index, even if one was created on attribute `attr`:
FOR doc In collection
FILTER doc.attr == null
RETURN doc
If the lookup value is non-constant, a sparse index may or may not be used, depending on
the other types of conditions in the query. If the optimizer can safely determine that
the lookup value cannot be `null`, a sparse index may be used. When uncertain, the optimizer
will not make use of a sparse index in a query in order to produce correct results.
For example, the following queries cannot use a sparse index on `attr` because the optimizer
will not know beforehand whether the comparsion values for `doc.attr` will include `null`:
FOR doc In collection
FILTER doc.attr == SOME_FUNCTION(...)
RETURN doc
FOR other IN otherCollection
FOR doc In collection
FILTER doc.attr == other.attr
RETURN doc
Sparse skiplist indexes can be used for sorting if the optimizer can safely detect that the
index range does not include `null` for any of the index attributes.
* inspection of AQL data-modification queries will now detect if the data-modification part
of the query can run in lockstep with the data retrieval part of the query, or if the data
retrieval part must be executed before the data modification can start.
Executing the two in lockstep allows using much smaller buffers for intermediate results
and starts the actual data-modification operations much earlier than if the two phases
were executed seperately.
* Allow dynamic attribute names in AQL object literals
This allows using arbitrary expressions to construct attribute names in object
literals specified in AQL queries. To disambiguate expressions and other unquoted
attribute names, dynamic attribute names need to be enclosed in brackets (`[` and `]`).
Example:
FOR i IN 1..100
RETURN { [ CONCAT('value-of-', i) ] : i }
* make AQL optimizer rule "use-index-for-sort" remove sort also in case a non-sorted
index (e.g. a hash index) is used for only equality lookups and all sort attributes
are covered by the index.
Example that does not require an extra sort (needs hash index on `value`):
FOR doc IN collection FILTER doc.value == 1 SORT doc.value RETURN doc
Another example that does not require an extra sort (with hash index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 && doc.value2 == 2 SORT doc.value1, doc.value2 RETURN doc
* make AQL optimizer rule "use-index-for-sort" remove sort also in case the sort critieria
excludes the left-most index attributes, but the left-most index attributes are used
by the index for equality-only lookups.
Example that can use the index for sorting (needs skiplist index on `value1`, `value2`):
FOR doc IN collection FILTER doc.value1 == 1 SORT doc.value2 RETURN doc
* added selectivity estimates for primary index, edge index, and hash index
The selectivity estimates are returned by the `GET /_api/index` REST API method
in a sub-attribute `selectivityEstimate` for each index that supports it. This
attribute will be omitted for indexes that do not provide selectivity estimates.
If provided, the selectivity estimate will be a numeric value between 0 and 1.
Selectivity estimates will also be reported in the result of `collection.getIndexes()`
for all indexes that support this. If no selectivity estimate can be determined for
an index, the attribute `selectivityEstimate` will be omitted here, too.
The web interface also shows selectivity estimates for each index that supports this.
Currently the following index types can provide selectivity estimates:
- primary index
- edge index
- hash index (unique and non-unique)
No selectivity estimates will be provided when running in cluster mode.
* fixed issue #1226: arangod log issues
* added additional logger if arangod is started in foreground mode on a tty
* added AQL optimizer rule "move-calculations-down"
* use exclusive native SRWLocks on Windows instead of native mutexes
* added AQL functions MD5, SHA1, and RANDOM_TOKEN.
* reduced number of string allocations when parsing certain AQL queries
parsing numbers (integers or doubles) does not require a string allocation
per number anymore
* RequestContext#bodyParam now accepts arbitrary joi schemas and rejects invalid (but well-formed) request bodies.
* enforce that AQL user functions are wrapped inside JavaScript function () declarations
AQL user functions were always expected to be wrapped inside a JavaScript function, but previously
this was not enforced when registering a user function. Enforcing the AQL user functions to be contained
inside functions prevents functions from doing some unexpected things that may have led to undefined
behavior.
-- ArangoDB Maintainer <info@arangodb.org> Mon, 16 Feb 2015 13:36:48 +0100
arangodb (2.4.3-1.1) stable; urgency=low
* Changed to Version 2.4.3
* fix multi-threading with openssl when running under Windows
* fix timeout on socket operations when running under Windows
* Fixed an error in Foxx routing which caused some apps that worked in 2.4.1 to fail with status 500: `undefined is not a function` errors in 2.4.2
This error was occurring due to seldom internal rerouting introduced by the malformed application handler.
-- ArangoDB Maintainer <info@arangodb.org> Fri, 06 Feb 2015 12:06:18 +0100
arangodb (2.4.2-1.1) stable; urgency=low
* Changed to Version 2.4.2
* added custom visitor functionality for AQL traversals
This allows more complex result processing in traversals triggered by AQL. A few examples
are shown in [this article](http://jsteemann.github.io/blog/2015/01/28/using-custom-visitors-in-aql-graph-traversals/).
* improved number of results estimated for nodes of type EnumerateListNode and SubqueryNode
in AQL explain output
* added AQL explain helper to explain arbitrary AQL queries
The helper function prints the query execution plan and the indexes to be used in the
query. It can be invoked from the ArangoShell or the web interface as follows:
require("org/arangodb/aql/explainer").explain(query);
* enable use of indexes for certain AQL conditions with non-equality predicates, in
case the condition(s) also refer to indexed attributes
The following queries will now be able to use indexes:
FILTER a.indexed == ... && a.indexed != ...
FILTER a.indexed == ... && a.nonIndexed != ...
FILTER a.indexed == ... && ! (a.indexed == ...)
FILTER a.indexed == ... && ! (a.nonIndexed == ...)
FILTER a.indexed == ... && ! (a.indexed != ...)
FILTER a.indexed == ... && ! (a.nonIndexed != ...)
FILTER (a.indexed == ... && a.nonIndexed == ...) || (a.indexed == ... && a.nonIndexed == ...)
FILTER (a.indexed == ... && a.nonIndexed != ...) || (a.indexed == ... && a.nonIndexed != ...)
* Fixed spuriously occurring "collection not found" errors when running queries on local
collections on a cluster DB server
* Fixed upload of Foxx applications to the server for apps exceeding approx. 1 MB zipped.
* Malformed Foxx applications will now return a more useful error when any route is requested.
In Production a Foxx app mounted on /app will display an html page on /app/* stating a 503 Service temporarily not available.
It will not state any information about your Application.
Before it was a 404 Not Found without any information and not distinguishable from a correct not found on your route.
In Development Mode the html page also contains information about the error occured.
* Unhandled errors thrown in Foxx routes are now handled by the Foxx framework itself.
In Production the route will return a status 500 with a body {error: "Error statement"}.
In Development the route will return a status 500 with a body {error: "Error statement", stack: "..."}
Before, it was status 500 with a plain text stack including ArangoDB internal routing information.
* The Applications tab in web interface will now request development apps more often.
So if you have a fixed a syntax error in your app it should always be visible after reload.
-- ArangoDB Maintainer <info@arangodb.org> Fri, 30 Jan 2015 19:09:36 +0100
arangodb (2.4.1-1.1) stable; urgency=low
* Changed to Version 2.4.1
* improved WAL recovery output
* fixed certain OR optimizations in AQL optimizer
* better diagnostics for arangoimp
* fixed invalid result of HTTP REST API method `/_admin/foxx/rescan`
* fixed possible segmentation fault when passing a Buffer object into a V8 function
as a parameter
* updated AQB module to 1.8.0.
-- ArangoDB Maintainer <info@arangodb.org> Mon, 19 Jan 2015 19:25:56 +0100
arangodb (2.4.0-1.1) stable; urgency=low
* Changed to Version 2.4.0
* fixed V8 integration-related crashes
* make `fs.move(src, dest)` also fail when both `src` and `dest` are
existing directories. This ensures the same behavior of the move operation
on different platforms.
* fixed AQL insert operation for multi-shard collections in cluster
* added optional return value for AQL data-modification queries.
This allows returning the documents inserted, removed or updated with the query, e.g.
FOR doc IN docs REMOVE doc._key IN docs LET removed = OLD RETURN removed
FOR doc IN docs INSERT { } IN docs LET inserted = NEW RETURN inserted
FOR doc IN docs UPDATE doc._key WITH { } IN docs LET previous = OLD RETURN previous
FOR doc IN docs UPDATE doc._key WITH { } IN docs LET updated = NEW RETURN updated
The variables `OLD` and `NEW` are automatically available when a `REMOVE`, `INSERT`,
`UPDATE` or `REPLACE` statement is immediately followed by a `LET` statement.
Note that the `LET` and `RETURN` statements in data-modification queries are not as
flexible as the general versions of `LET` and `RETURN`. When returning documents from
data-modification operations, only a single variable can be assigned using `LET`, and
the assignment can only be either `OLD` or `NEW`, but not an arbitrary expression. The
`RETURN` statement also allows using the just-created variable only, and no arbitrary
expressions.
-- ArangoDB Maintainer <info@arangodb.org> Tue, 13 Jan 2015 00:53:47 +0100
arangodb (2.4.0b1-1.1) stable; urgency=low
* Changed to Version 2.4.0-beta1
* fixed superstates in FoxxGenerator
* fixed issue #1065: Aardvark: added creation of documents and edges with _key property
* fixed issue #1198: Aardvark: current aql editor query is now cached
* Upgraded V8 version from 3.16.14 to 3.29.59
* Added Foxx generator for building Hypermedia APIs
A more detailed description is [here](https://www.arangodb.com/2014/12/08/building-hypermedia-apis-foxxgenerator)
* New `Applications` tab in web interface:
The `applications` tab got a complete redesign.
It will now only show applications that are currently running on ArangoDB.
For a selected application, a new detailed view has been created.
This view provides a better overview of the app:
* author
* license
* version
* contributors
* download links
* API documentation
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 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
be installed on the server. Starting with a new Foxx app has never been easier.
* fixed issue #1102: Aardvark: Layout bug in documents overview
The documents overview was entirely destroyed in some situations on Firefox.
We replaced the plugin we used there.
* fixed issue #1168: Aardvark: pagination buttons jumping
* fixed issue #1161: Aardvark: Click on Import JSON imports previously uploaded file
* removed configure options `--enable-all-in-one-v8`, `--enable-all-in-one-icu`,
and `--enable-all-in-one-libev`.
* global internal rename to fix naming incompatibilities with JSON:
Internal functions with names containing `array` have been renamed to `object`,
internal functions with names containing `list` have been renamed to `array`.
The renaming was mainly done in the C++ parts. The documentation has also been
adjusted so that the correct JSON type names are used in most places.
The change also led to the addition of a few function aliases in AQL:
* `TO_LIST` now is an alias of the new `TO_ARRAY`
* `IS_LIST` now is an alias of the new `IS_ARRAY`
* `IS_DOCUMENT` now is an alias of the new `IS_OBJECT`
The changed also renamed the option `mergeArrays` to `mergeObjects` for AQL
data-modification query options and HTTP document modification API
* AQL: added optimizer rule "remove-filter-covered-by-index"
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 because the query requires less
computation.
* AQL: added optimizer rule "remove-sort-rand"
This rule removes a `SORT RAND()` expression from a query and moves the random
iteration into the appropriate `EnumerateCollectionNode`. This is more efficient
than individually enumerating and then sorting randomly.
* AQL: range optimizations for IN and OR
This change enables usage of indexes for 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 filters are accessing 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
* fixed issue #500: AQL parentheses issue
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`
This allows more efficient group count calculation queries, e.g.
FOR doc IN collection
COLLECT age = doc.age WITH COUNT INTO length
RETURN { age: age, count: length }
A count-only query is also possible:
FOR doc IN collection
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.
This will make new ArangoDB installations unaccessible from clients other than
localhost unless changed. This is a security feature.
To make ArangoDB accessible from any client, change the server's configuration
(`--server.endpoint`) to either `tcp://0.0.0.0:8529` or the server's publicly
-- ArangoDB Maintainer <info@arangodb.org> Fri, 26 Dec 2014 13:54:35 +0100
arangodb (2.4.0a7-1.1) stable; urgency=low
* Changed to Version 2.4.0-alpha7
* fixed superstates in FoxxGenerator
* fixed issue #1065: Aardvark: added creation of documents and edges with _key property
* fixed issue #1198: Aardvark: current aql editor query is now cached
* Upgraded V8 version from 3.16.14 to 3.29.59
* Added Foxx generator for building Hypermedia APIs
A more detailed description is [here](https://www.arangodb.com/2014/12/08/building-hypermedia-apis-foxxgenerator)
* New `Applications` tab in web interface:
The `applications` tab got a complete redesign.
It will now only show applications that are currently running on ArangoDB.
For a selected application, a new detailed view has been created.
This view provides a better overview of the app:
* author
* license
* version
* contributors
* download links
* API documentation
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 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
be installed on the server. Starting with a new Foxx app has never been easier.
* fixed issue #1102: Aardvark: Layout bug in documents overview
The documents overview was entirely destroyed in some situations on Firefox.
We replaced the plugin we used there.
* fixed issue #1168: Aardvark: pagination buttons jumping
* fixed issue #1161: Aardvark: Click on Import JSON imports previously uploaded file
* removed configure options `--enable-all-in-one-v8`, `--enable-all-in-one-icu`,
and `--enable-all-in-one-libev`.
* global internal rename to fix naming incompatibilities with JSON:
Internal functions with names containing `array` have been renamed to `object`,
internal functions with names containing `list` have been renamed to `array`.
The renaming was mainly done in the C++ parts. The documentation has also been
adjusted so that the correct JSON type names are used in most places.
The change also led to the addition of a few function aliases in AQL:
* `TO_LIST` now is an alias of the new `TO_ARRAY`
* `IS_LIST` now is an alias of the new `IS_ARRAY`
* `IS_DOCUMENT` now is an alias of the new `IS_OBJECT`
The changed also renamed the option `mergeArrays` to `mergeObjects` for AQL
data-modification query options and HTTP document modification API
* AQL: added optimizer rule "remove-filter-covered-by-index"
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 because the query requires less
computation.
* AQL: added optimizer rule "remove-sort-rand"
This rule removes a `SORT RAND()` expression from a query and moves the random
iteration into the appropriate `EnumerateCollectionNode`. This is more efficient
than individually enumerating and then sorting randomly.
* AQL: range optimizations for IN and OR
This change enables usage of indexes for 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 filters are accessing 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
* fixed issue #500: AQL parentheses issue
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`
This allows more efficient group count calculation queries, e.g.
FOR doc IN collection
COLLECT age = doc.age WITH COUNT INTO length
RETURN { age: age, count: length }
A count-only query is also possible:
FOR doc IN collection
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.
This will make new ArangoDB installations unaccessible from clients other than
localhost unless changed. This is a security feature.
To make ArangoDB accessible from any client, change the server's configuration
(`--server.endpoint`) to either `tcp://0.0.0.0:8529` or the server's publicly
-- ArangoDB Maintainer <info@arangodb.org> Thu, 25 Dec 2014 10:36:12 +0100
arangodb (2.4.0a6-1.1) stable; urgency=low
* Changed to Version 2.4.0-alpha6
* fixed superstates in FoxxGenerator
* Upgraded V8 version from 3.16.14 to 3.29.59
* Added Foxx generator for building Hypermedia APIs
A more detailed description is [here](https://www.arangodb.com/2014/12/08/building-hypermedia-apis-foxxgenerator)
* New `Applications` tab in web interface:
The `applications` tab got a complete redesign.
It will now only show applications that are currently running on ArangoDB.
For a selected application, a new detailed view has been created.
This view provides a better overview of the app:
* author
* license
* version
* contributors
* download links
* API documentation
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 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
be installed on the server. Starting with a new Foxx app has never been easier.
* fixed issue #1102: Aardvark: Layout bug in documents overview
The documents overview was entirely destroyed in some situations on Firefox.
We replaced the plugin we used there.
* fixed issue #1168: Aardvark: pagination buttons jumping
* fixed issue #1161: Aardvark: Click on Import JSON imports previously uploaded file
* removed configure options `--enable-all-in-one-v8`, `--enable-all-in-one-icu`,
and `--enable-all-in-one-libev`.
* global internal rename to fix naming incompatibilities with JSON:
Internal functions with names containing `array` have been renamed to `object`,
internal functions with names containing `list` have been renamed to `array`.
The renaming was mainly done in the C++ parts. The documentation has also been
adjusted so that the correct JSON type names are used in most places.
The change also led to the addition of a few function aliases in AQL:
* `TO_LIST` now is an alias of the new `TO_ARRAY`
* `IS_LIST` now is an alias of the new `IS_ARRAY`
* `IS_DOCUMENT` now is an alias of the new `IS_OBJECT`
The changed also renamed the option `mergeArrays` to `mergeObjects` for AQL
data-modification query options and HTTP document modification API
* AQL: added optimizer rule "remove-filter-covered-by-index"
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 because the query requires less
computation.
* AQL: range optimizations for IN and OR
This change enables usage of indexes for 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 filters are accessing 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
* fixed issue #500: AQL parentheses issue
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`
This allows more efficient group count calculation queries, e.g.
FOR doc IN collection
COLLECT age = doc.age WITH COUNT INTO length
RETURN { age: age, count: length }
A count-only query is also possible:
FOR doc IN collection
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.
This will make new ArangoDB installations unaccessible from clients other than
localhost unless changed. This is a security feature.
To make ArangoDB accessible from any client, change the server's configuration
(`--server.endpoint`) to either `tcp://0.0.0.0:8529` or the server's publicly
-- ArangoDB Maintainer <info@arangodb.org> Fri, 19 Dec 2014 21:00:40 +0100
arangodb (2.4.0a5-1.1) stable; urgency=low
* Changed to Version 2.4.0-alpha5
* switch to new V8 engine 3.29.59
-- ArangoDB Maintainer <info@arangodb.org> Fri, 19 Dec 2014 13:46:24 +0100
arangodb (2.4.0a4-1.1) stable; urgency=low
* Changed to Version 2.4.0-alpha4
* switch to new V8 engine 3.29.59
-- ArangoDB Maintainer <info@arangodb.org> Fri, 19 Dec 2014 10:28:16 +0100
arangodb (2.4.0a3-1.1) stable; urgency=low
* Changed to Version 2.4.0-alpha3
* switch to new V8 engine 3.29.59
-- ArangoDB Maintainer <info@arangodb.org> Thu, 18 Dec 2014 17:45:48 +0100
arangodb (2.4.0a2-1.1) stable; urgency=low
* Changed to Version 2.4.0-alpha2
* fixed superstates in FoxxGenerator
-- ArangoDB Maintainer <info@arangodb.org> Fri, 28 Nov 2014 12:54:02 +0100
arangodb (2.4.0a1-1.1) stable; urgency=low
* Changed to Version 2.4.0-alpha1
* fixed replication of `_graphs` collection
* added AQL list functions `PUSH`, `POP`, `UNSHIFT`, `SHIFT`, `REMOVE_VALUES`,
`REMOVE_VALUE`, `REMOVE_NTH` and `APPEND`
* added AQL functions `CALL` and `APPLY` to dynamically call other functions
* fixed AQL optimizer cost estimation for LIMIT node
-- ArangoDB Maintainer <info@arangodb.org> Tue, 25 Nov 2014 10:48:08 +0100
arangodb (2.3.0-1.1) stable; urgency=low
* Changed to Version 2.3.0
* fixed syslog flags. `--log.syslog` is deprecated and setting it has no effect,
`--log.facility` now works as described. Application name has been changed from
`triagens` to `arangod`. It can be changed using `--log.application`. The syslog
will only contain the actual log message. The datetime prefix is omiited.
* fixed deflate in SimpleHttpClient
* hide system applications in **Applications** tab by default
Display of system applications can be toggled by using the *system applications*
toggle in the UI.
* added HTTP REST API for managing tasks (`/_api/tasks`)
* allow passing character lists as optional parameter to AQL functions `TRIM`,
`LTRIM` and `RTRIM`
These functions now support trimming using custom character lists. If no character
lists are specified, all whitespace characters will be removed as previously:
TRIM(" foobar\t \r\n ") // "foobar"
TRIM(";foo;bar;baz, ", "; ") // "foo;bar;baz"
* added AQL string functions `LTRIM`, `RTRIM`, `FIND_FIRST`, `FIND_LAST`, `SPLIT`,
`SUBSTITUTE`
* added AQL functions `ZIP`, `VALUES` and `PERCENTILE`
* made AQL functions `CONCAT` and `CONCAT_SEPARATOR` work with list arguments
* dynamically create extra dispatcher threads if required
* fixed issue #1097: schemas in the API docs no longer show required properties as optional
-- ArangoDB Maintainer <info@arangodb.org> Tue, 18 Nov 2014 19:02:18 +0100
arangodb (2.3.0b2-1.1) stable; urgency=low
* Changed to Version 2.3.0-beta2
* front-end: new icons for uploading and downloading JSON documents into a collection
* front-end: fixed documents pagination css display error
* front-end: fixed flickering of the progress view
* front-end: fixed missing event for documents filter function
* front-end: jsoneditor: added CMD+Return (Mac) CTRL+Return (Linux/Win) shortkey for
saving a document
* front-end: added information tooltip for uploading json documents.
* front-end: added database management view to the collapsed navigation menu
* front-end: added collection truncation feature
* fixed issue #1086: arangoimp: Odd errors if arguments are not given properly
* performance improvements for AQL queries that use JavaScript-based expressions
internally
* added AQL geo functions `WITHIN_RECTANGLE` and `IS_IN_POLYGON`
* fixed non-working query results download in AQL editor of web interface
* removed debug print message in AQL editor query export routine
* fixed issue #1075: Aardvark: user name required even if auth is off #1075
The fix for this prefills the username input field with the current user's
accout name if any and `root` (the default username) otherwise. Additionally,
the tooltip text has been slightly adjusted.
* fixed issue #1069: Add 'raw' link to swagger ui so that the raw swagger
json can easily be retrieved
This adds a link to the Swagger API docs to an application's detail view in
the **Applications** tab of the web interface. The link produces the Swagger
JSON directly. If authentication is turned on, the link requires authentication,
too.
* documentation updates
* added dedicated `NOT IN` operator for AQL
Previously, a `NOT IN` was only achievable by writing a negated `IN` condition:
FOR i IN ... FILTER ! (i IN [ 23, 42 ]) ...
This can now alternatively be expressed more intuitively as follows:
FOR i IN ... FILTER i NOT IN [ 23, 42 ] ...
* added alternative logical operator syntax for AQL
Previously, the logical operators in AQL could only be written as:
- `&&`: logical and
- `||`: logical or
- `!`: negation
ArangoDB 2.3 introduces the alternative variants for these operators:
- `AND`: logical and
- `OR`: logical or
- `NOT`: negation
The new syntax is just an alternative to the old syntax, allowing easier
migration from SQL. The old syntax is still fully supported and will be.
* improved output of `ArangoStatement.parse()` and POST `/_api/query`
If an AQL query can be parsed without problems, The return value of
`ArangoStatement.parse()` now contains an attribute `ast` with the abstract
syntax tree of the query (before optimizations). Though this is an internal
representation of the query and is subject to change, it can be used to inspect
how ArangoDB interprets a given query.
* improved `ArangoStatement.explain()` and POST `/_api/explain`
The commands for explaining AQL queries have been improved.
* added command-line option `--javascript.v8-contexts` to control the number of
V8 contexts created in arangod.
Previously, the number of V8 contexts was equal to the number of server threads
(as specified by option `--server.threads`). However, it may be sensible to
create different amounts of threads and V8 contexts. If the option is not
specified, the number of V8 contexts created will be equal to the number of
server threads. Thus no change in configuration is required to keep the old
behavior.
However, the default configuration files shipped with ArangoDB have been changed.
The number of server threads has been increased in the configuration files, and
the number of V8 contexts is now explicitly set in the configuration files (to
the same value as the number of server threads was set to in 2.2).
If you are using the default config files or merge them with your local config files,
please review if the higher default number of server threads is okay in your
environment. Additionally you should verify that the number of V8 contexts
created (as specified in option `--javascript.v8-contexts`) is okay.
* removed index type "bitarray"
Bitarray indexes were only half-way documented and integrated in previous versions
of ArangoDB so their benefit was limited. The support for bitarray indexes has
thus been removed in ArangoDB 2.3. It is not possible to create indexes of type
"bitarray" with ArangoDB 2.3.
When a collection is openend that contains a bitarray index definition created
with a previous version of ArangoDB, ArangoDB will ignore it and log the following
warning:
index type 'bitarray' is not supported in this version of ArangoDB and is ignored
Future versions of ArangoDB may automatically remove such index definitions so the
warnings will eventually disappear.
* removed internal "_admin/modules/flush" in order to fix requireApp
* added basic support for handling binary data in Foxx
Requests with binary payload can be processed in Foxx applications by
using the new method `res.rawBodyBuffer()`. This will return the unparsed request
body as a Buffer object.
There is now also the method `req.requestParts()` available in Foxx to retrieve
the individual components of a multipart HTTP request.
Buffer objects can now be used when setting the response body of any Foxx action.
Additionally, `res.send()` has been added as a convenience method for returning
strings, JSON objects or buffers from a Foxx action:
res.send("<p>some HTML</p>");
res.send({ success: true });
res.send(new Buffer("some binary data"));
The convenience method `res.sendFile()` can now be used to easily return the
contents of a file from a Foxx action:
res.sendFile(applicationContext.foxxFilename("image.png"));
`fs.write` now accepts not only strings but also Buffer objects as second parameter:
fs.write(filename, "some data");
fs.write(filename, new Buffer("some binary data"));
`fs.readBuffer` can be used to return the contents of a file in a Buffer object.
* improved performance of insertion into non-unique hash indexes significantly in case
many duplicate keys are used in the index
* issue #1042: set time zone in log output
the command-line option `--log.use-local-time` was added to print dates and times in
the server-local timezone instead of UTC
* command-line options that require a boolean value now validate the
-- ArangoDB Maintainer <info@arangodb.org> Sat, 08 Nov 2014 00:09:03 +0100
arangodb (2.3.0b1-1.1) stable; urgency=low
* Changed to Version 2.3.0-beta1
* added command-line option `--javascript.v8-contexts` to control the number of
V8 contexts created in arangod.
Previously, the number of V8 contexts was equal to the number of server threads
(as specified by option `--server.threads`). However, it may be sensible to
create different amounts of threads and V8 contexts. If the option is not
specified, the number of V8 contexts created will be equal to the number of
server threads. Thus no change in configuration is required to keep the old
behavior.
* removed bitarray indexes
* removed internal "_admin/modules/flush" in order to fix requireApp
* added basic support for handling binary data in Foxx
Buffer objects can now be used when setting the response body of any Foxx action.
Additionally, `res.send()` has been added as a convenience method for returning
strings, JSON objects or buffers from a Foxx action:
res.send("<p>some HTML</p>");
res.send({ success: true });
res.send(new Buffer("some binary data"));
The convenience method `res.sendFile()` can now be used to easily return the
contents of a file from a Foxx action:
res.sendFile(applicationContext.foxxFilename("image.png"));
`fs.write` now accepts not only strings but also Buffer objects as second parameter:
fs.write(filename, "some data");
fs.write(filename, new Buffer("some binary data"));
`fs.readBuffer` can be used to return the contents of a file in a Buffer object.
* improved insert performance of non-unique hash index inserts significantly in case
many duplicate keys are used in the index
* issue #1042: set time zone in log output
the command-line option `--log.use-local-time` was added to print dates and times in
the server-local timezone instead of UTC
* command-line options that require a boolean value now validate the
-- ArangoDB Maintainer <info@arangodb.org> Sun, 02 Nov 2014 01:08:15 +0100
arangodb (2.3.0a6-1.1) stable; urgency=low
* Changed to Version 2.3.0-alpha6
* removed internal "_admin/modules/flush" in order to fix requireApp
* added basic support for handling binary data in Foxx
Buffer objects can now be used when setting the response body of any Foxx action.
Additionally, `res.send()` has been added as a convenience method for returning
strings, JSON objects or buffers from a Foxx action:
res.send("<p>some HTML</p>");
res.send({ success: true });
res.send(new Buffer("some binary data"));
The convenience method `res.sendFile()` can now be used to easily return the
contents of a file from a Foxx action:
res.sendFile(applicationContext.foxxFilename("image.png"));
`fs.write` now accepts not only strings but also Buffer objects as second parameter:
fs.write(filename, "some data");
fs.write(filename, new Buffer("some binary data"));
`fs.readBuffer` can be used to return the contents of a file in a Buffer object.
* improved insert performance of non-unique hash index inserts significantly in case
many duplicate keys are used in the index
* issue #1042: set time zone in log output
the command-line option `--log.use-local-time` was added to print dates and times in
the server-local timezone instead of UTC
* command-line options that require a boolean value now validate the
-- ArangoDB Maintainer <info@arangodb.org> Wed, 29 Oct 2014 15:30:13 +0100
arangodb (2.3.0a3-1.1) stable; urgency=low
* Changed to Version 2.3.0-alpha3
* Added a _relation function in the general-graph module.
This deprecated _directedRelation and _undirectedRelation.
ArangoDB does not offer any constraints for undirected edges
which caused some confusion of users how undirected relations
have to be handled. Relation now only supports directed relations
and the user can actively simulate undirected relations.
* changed return value of Foxx.applicationContext#collectionName:
Previously, the function could return invalid collection names because
invalid characters were not replaced in the application name prefix, only
in the collection name passed.
Now, the function replaces invalid characters also in the application name
prefix, which might to slightly different results for application names that
contained any characters outside the ranges [a-z], [A-Z] and [0-9].
* prevent XSS in AQL editor and logs view
* integrated tutorial into ArangoShell and web interface
* added option `--backslash-escape` for arangoimp when running CSV file imports
* front-end: added download feature for (filtered) documents
* front-end: added download feature for the results of a user query
* front-end: added function to move documents to another collection
* front-end: added sort-by attribute to the documents filter
* front-end: added sorting feature to database, graph management and user management view.
* issue #989: front-end: Databases view not refreshing after deleting a database
* issue #991: front-end: Database search broken
* front-end: added infobox which shows more information about a document (_id, _rev, _key) or
an edge (_id, _rev, _key, _from, _to). The from and to attributes are clickable and redirect
to their document location.
* front-end: added edit-mode for deleting multiple documents at the same time.
* front-end: added delete button to the detailed document/edge view.
* front-end: added visual feedback for saving documents/edges inside the editor (error/success).
* front-end: added auto-focusing for the first input field in a modal.
* front-end: added validation for user input in a modal.
* front-end: user defined queries are now stored inside the database and are bound to the current
user, instead of using the local storage functionality of the browsers. The outcome of this is
that user defined queries are now independently usable from any device. Also queries can now be
edited through the standard document editor of the front-end through the _users collection.
* front-end: added import and export functionality for user defined queries.
* front-end: added new keywords and functions to the aql-editor theme
* front-end: applied tile-style to the graph view
* front-end: now using the new graph api including multi-collection support
* front-end: foxx apps are now deleteable
* front-end: foxx apps are now installable and updateable through github, if github is their
origin.
* front-end: added foxx app version control. Multiple versions of a single foxx app are now
installable and easy to manage and are also arranged in groups.
* front-end: the user-set filter of a collection is now stored until the user navigates to
another collection.
* front-end: fetching and filtering of documents, statistics, and query operations are now
handled with asynchronous ajax calls.
* front-end: added progress indicator if the front-end is waiting for a server operation.
* front-end: fixed wrong count of documents in the documents view of a collection.
* front-end: fixed unexpected styling of the manage db view and navigation.
* front-end: fixed wrong handling of select fields in a modal view.
* front-end: fixed wrong positioning of some tooltips.
* automatically call `toJSON` function of JavaScript objects (if present)
when serializing them into database documents. This change allows
storing JavaScript date objects in the database in a sensible manner.
-- ArangoDB Maintainer <info@arangodb.org> Mon, 22 Sep 2014 20:30:35 +0200
arangodb (2.2.3-1.1) stable; urgency=low
* Changed to Version 2.2.3
* added `around` for Foxx controller
* added `type` option for HTTP API `GET /_api/document?collection=...`
This allows controlling the type of results to be returned. By default, paths to
documents will be returned, e.g.
[
`/_api/document/test/mykey1`,
`/_api/document/test/mykey2`,
...
]
To return a list of document ids instead of paths, the `type` URL parameter can be
set to `id`:
[
`test/mykey1`,
`test/mykey2`,
...
]
To return a list of document keys only, the `type` URL parameter can be set to `key`:
[
`mykey1`,
`mykey2`,
...
]
* properly capitalize HTTP response header field names in case the `x-arango-async`
HTTP header was used in a request.
* fixed several documentation issues
* speedup for several general-graph functions, AQL functions starting with `GRAPH_`
and traversals
-- ArangoDB Maintainer <info@arangodb.org> Tue, 02 Sep 2014 11:30:26 +0200
arangodb (2.2.3r1-1.1) stable; urgency=low
* Changed to Version 2.2.3-rc1
* added `type` option for HTTP API `GET /_api/document?collection=...`
This allows controlling the type of results to be returned. By default, paths to
documents will be returned, e.g.
[
`/_api/document/test/mykey1`,
`/_api/document/test/mykey2`,
...
]
To return a list of document ids instead of paths, the `type` URL parameter can be
set to `id`:
[
`test/mykey1`,
`test/mykey2`,
...
]
To return a list of document keys only, the `type` URL parameter can be set to `key`:
[
`mykey1`,
`mykey2`,
...
]
* properly capitalize HTTP response header field names in case the `x-arango-async`
HTTP header was used in a request.
* fixed several documentation issues
* speedup for several general-graph functions, AQL functions starting with `GRAPH_`
and traversals
-- ArangoDB Maintainer <info@arangodb.org> Mon, 01 Sep 2014 15:58:14 +0200
arangodb (2.2.2-1.1) stable; urgency=low
* Changed to Version 2.2.2
* allow storing non-reserved attribute names starting with an underscore
Previous versions of ArangoDB parsed away all attribute names that started with an
underscore (e.g. `_test', '_foo', `_bar`) on all levels of a document (root level
and sub-attribute levels). While this behavior was documented, it was unintuitive and
prevented storing documents inside other documents, e.g.:
{
"_key" : "foo",
"_type" : "mydoc",
"references" : [
{
"_key" : "something",
"_rev" : "...",
"value" : 1
},
{
"_key" : "something else",
"_rev" : "...",
"value" : 2
}
]
}
In the above example, previous versions of ArangoDB removed all attributes and
sub-attributes that started with underscores, meaning the embedded documents would lose
some of their attributes. 2.2.2 should preserve such attributes, and will also allow
storing user-defined attribute names on the top-level even if they start with underscores
(such as `_type` in the above example).
* fix conversion of JavaScript String, Number and Boolean objects to JSON.
Objects created in JavaScript using `new Number(...)`, `new String(...)`, or
`new Boolean(...)` were not converted to JSON correctly.
* fixed a race condition on task registration (i.e. `require("org/arangodb/tasks").register()`)
this race condition led to undefined behavior when a just-created task with no offset and
no period was instantly executed and deleted by the task scheduler, before the `register`
function returned to the caller.
* changed run-tests.sh to execute all suitable tests.
* switch to new version of gyp
* fixed upgrade button
-- ArangoDB Maintainer <info@arangodb.org> Fri, 08 Aug 2014 12:26:37 +0200
arangodb (2.2.2r1-1.1) stable; urgency=low
* Changed to Version 2.2.2-rc1
* fixed a race condition on task registration (i.e. `require("org/arangodb/tasks").register()`)
this race condition led to undefined behavior when a just-created task with no offset and
no period was instantly executed and deleted by the task scheduler, before the `register`
function returned to the caller.
* changed run-tests.sh to execute all suitable tests.
* switch to new version of gyp
* fixed upgrade button
-- ArangoDB Maintainer <info@arangodb.org> Wed, 06 Aug 2014 11:21:54 +0200
arangodb (2.2.1-1.1) stable; urgency=low
* Changed to Version 2.2.1
* fixed issue with --check-version: when creating a new database the check failed
* issue #947 Foxx applicationContext missing some properties
* added startup option `--wal.suppress-shape-information`
Setting this option to `true` will reduce memory and disk space usage and require
less CPU time when modifying documents or edges. It should therefore be turned on
for standalone ArangoDB servers. However, for servers that are used as replication
masters, setting this option to `true` will effectively disable the usage of the
write-ahead log for replication, so it should be set to `false` for any replication
master servers.
The default value for this option is `false`.
* added optional `ttl` attribute to specify result cursor expiration for HTTP API method
`POST /_api/cursor`
The `ttl` attribute can be used to prevent cursor results from timing out too early.
* (reported by Christian Neubauer):
The problem was that in Google's V8, signed and unsigned chars are not always declared cleanly.
so we need to force v8 to compile with forced signed chars which is done by the Flag:
-fsigned-char
at least it is enough to follow the instructions of compiling arango on rasperry
and add "CFLAGS='-fsigned-char'" to the make command of V8 and remove the armv7=0
* Fixed a bug with the replication client. In the case of single document
transactions the collection was not write locked.
-- ArangoDB Maintainer <info@arangodb.org> Thu, 24 Jul 2014 12:22:18 +0200
arangodb (2.2.1r1-1.1) stable; urgency=low
* Changed to Version 2.2.1-rc1
* fixed issue with --check-version: when creating a new database the check failed
* issue #947 Foxx applicationContext missing some properties
* added startup option `--wal.suppress-shape-information`
Setting this option to `true` will reduce memory and disk space usage and require
less CPU time when modifying documents or edges. It should therefore be turned on
for standalone ArangoDB servers. However, for servers that are used as replication
masters, setting this option to `true` will effectively disable the usage of the
write-ahead log for replication, so it should be set to `false` for any replication
master servers.
The default value for this option is `false`.
* added optional `ttl` attribute to specify result cursor expiration for HTTP API method
`POST /_api/cursor`
The `ttl` attribute can be used to prevent cursor results from timing out too early.
* (reported by Christian Neubauer):
The problem was that in Google's V8, signed and unsigned chars are not always declared cleanly.
so we need to force v8 to compile with forced signed chars which is done by the Flag:
-fsigned-char
at least it is enough to follow the instructions of compiling arango on rasperry
and add "CFLAGS='-fsigned-char'" to the make command of V8 and remove the armv7=0
* Fixed a bug with the replication client. In the case of single document
transactions the collection was not write locked.
-- ArangoDB Maintainer <info@arangodb.org> Wed, 23 Jul 2014 18:37:33 +0200
arangodb (2.2.0-1.1) stable; urgency=low
* Changed to Version 2.2.0
* The replication methods `logger.start`, `logger.stop` and `logger.properties` are
no-ops in ArangoDB 2.2 as there is no separate replication logger anymore. Data changes
are logged into the write-ahead log in ArangoDB 2.2, and not separately by the
replication logger. The replication logger object is still there in ArangoDB 2.2 to
ensure backwards-compatibility, however, logging cannot be started, stopped or
configured anymore. Using any of these methods will do nothing.
This also affects the following HTTP API methods:
- `PUT /_api/replication/logger-start`
- `PUT /_api/replication/logger-stop`
- `GET /_api/replication/logger-config`
- `PUT /_api/replication/logger-config`
Using any of these methods is discouraged from now on as they will be removed in
future versions of ArangoDB.
* INCOMPATIBLE CHANGE: replication of transactions has changed. Previously, transactions
were logged on a master in one big block and shipped to a slave in one block, too.
Now transactions will be logged and replicated as separate entries, allowing transactions
to be bigger and also ensure replication progress.
This change also affects the behavior of the `stop` method of the replication applier.
If the replication applier is now stopped manually using the `stop` method and later
restarted using the `start` method, any transactions that were unfinished at the
point of stopping will be aborted on a slave, even if they later commit on the master.
In ArangoDB 2.2, stopping the replication applier manually should be avoided unless the
goal is to stop replication permanently or to do a full resync with the master anyway.
If the replication applier still must be stopped, it should be made sure that the
slave has fetched and applied all pending operations from a master, and that no
extra transactions are started on the master before the `stop` command on the slave
is executed.
Replication of transactions in ArangoDB 2.2 might also lock the involved collections on
the slave while a transaction is either committed or aborted on the master and the
change has been replicated to the slave. This change in behavior may be important for
slave servers that are used for read-scaling. In order to avoid long lasting collection
locks on the slave, transactions should be kept small.
The `_replication` system collection is not used anymore in ArangoDB 2.2 and its usage is
discouraged.
* INCOMPATIBLE CHANGE: the figures reported by the `collection.figures` method
now only reflect documents and data contained in the journals and datafiles of
collections. Documents or deletions contained only in the write-ahead log will
not influence collection figures until the write-ahead log garbage collection
kicks in. The figures for a collection might therefore underreport the total
resource usage of a collection.
Additionally, the attributes `lastTick` and `uncollectedLogfileEntries` have been
added to the result of the `figures` operation and the HTTP API method
`PUT /_api/collection/figures`
* added `insert` method as an alias for `save`. Documents can now be inserted into
a collection using either method:
db.test.save({ foo: "bar" });
db.test.insert({ foo: "bar" });
* added support for data-modification AQL queries
* added AQL keywords `INSERT`, `UPDATE`, `REPLACE` and `REMOVE` (and `WITH`) to
support data-modification AQL queries.
Unquoted usage of these keywords for attribute names in AQL queries will likely
fail in ArangoDB 2.2. If any such attribute name needs to be used in a query, it
should be enclosed in backticks to indicate the usage of a literal attribute
name.
For example, the following query will fail in ArangoDB 2.2 with a parse error:
FOR i IN foo RETURN i.remove
and needs to be rewritten like this:
FOR i IN foo RETURN i.`remove`
* disallow storing of JavaScript objects that contain JavaScript native objects
of type `Date`, `Function`, `RegExp` or `External`, e.g.
db.test.save({ foo: /bar/ });
db.test.save({ foo: new Date() });
will now print
Error: <data> cannot be converted into JSON shape: could not shape document
Previously, objects of these types were silently converted into an empty object
(i.e. `{ }`).
To store such objects in a collection, explicitly convert them into strings
like this:
db.test.save({ foo: String(/bar/) });
db.test.save({ foo: String(new Date()) });
* The replication methods `logger.start`, `logger.stop` and `logger.properties` are
no-ops in ArangoDB 2.2 as there is no separate replication logger anymore. Data changes
are logged into the write-ahead log in ArangoDB 2.2, and not separately by the
replication logger. The replication logger object is still there in ArangoDB 2.2 to
ensure backwards-compatibility, however, logging cannot be started, stopped or
configured anymore. Using any of these methods will do nothing.
This also affects the following HTTP API methods:
- `PUT /_api/replication/logger-start`
- `PUT /_api/replication/logger-stop`
- `GET /_api/replication/logger-config`
- `PUT /_api/replication/logger-config`
Using any of these methods is discouraged from now on as they will be removed in
future versions of ArangoDB.
* INCOMPATIBLE CHANGE: replication of transactions has changed. Previously, transactions
were logged on a master in one big block and shipped to a slave in one block, too.
Now transactions will be logged and replicated as separate entries, allowing transactions
to be bigger and also ensure replication progress.
This change also affects the behavior of the `stop` method of the replication applier.
If the replication applier is now stopped manually using the `stop` method and later
restarted using the `start` method, any transactions that were unfinished at the
point of stopping will be aborted on a slave, even if they later commit on the master.
In ArangoDB 2.2, stopping the replication applier manually should be avoided unless the
goal is to stop replication permanently or to do a full resync with the master anyway.
If the replication applier still must be stopped, it should be made sure that the
slave has fetched and applied all pending operations from a master, and that no
extra transactions are started on the master before the `stop` command on the slave
is executed.
Replication of transactions in ArangoDB 2.2 might also lock the involved collections on
the slave while a transaction is either committed or aborted on the master and the
change has been replicated to the slave. This change in behavior may be important for
slave servers that are used for read-scaling. In order to avoid long lasting collection
locks on the slave, transactions should be kept small.
The `_replication` system collection is not used anymore in ArangoDB 2.2 and its usage is
discouraged.
* INCOMPATIBLE CHANGE: the figures reported by the `collection.figures` method
now only reflect documents and data contained in the journals and datafiles of
collections. Documents or deletions contained only in the write-ahead log will
not influence collection figures until the write-ahead log garbage collection
kicks in. The figures for a collection might therefore underreport the total
resource usage of a collection.
Additionally, the attributes `lastTick` and `uncollectedLogfileEntries` have been
added to the result of the `figures` operation and the HTTP API method
`PUT /_api/collection/figures`
* added `insert` method as an alias for `save`. Documents can now be inserted into
a collection using either method:
db.test.save({ foo: "bar" });
db.test.insert({ foo: "bar" });
* added support for data-modification AQL queries
* added AQL keywords `INSERT`, `UPDATE`, `REPLACE` and `REMOVE` (and `WITH`) to
support data-modification AQL queries.
Unquoted usage of these keywords for attribute names in AQL queries will likely
fail in ArangoDB 2.2. If any such attribute name needs to be used in a query, it
should be enclosed in backticks to indicate the usage of a literal attribute
name.
For example, the following query will fail in ArangoDB 2.2 with a parse error:
FOR i IN foo RETURN i.remove
and needs to be rewritten like this:
FOR i IN foo RETURN i.`remove`
* disallow storing of JavaScript objects that contain JavaScript native objects
of type `Date`, `Function`, `RegExp` or `External`, e.g.
db.test.save({ foo: /bar/ });
db.test.save({ foo: new Date() });
will now print
Error: <data> cannot be converted into JSON shape: could not shape document
Previously, objects of these types were silently converted into an empty object
(i.e. `{ }`).
To store such objects in a collection, explicitly convert them into strings
like this:
db.test.save({ foo: String(/bar/) });
db.test.save({ foo: String(new Date()) });
* honor startup option `--server.disable-statistics` when deciding whether or not
to start periodic statistics collection jobs
Previously, the statistics collection jobs were started even if the server was
started with the `--server.disable-statistics` flag being set to `true`
* removed startup option `--random.no-seed`
This option had no effect in previous versions of ArangoDB and was thus removed.
* removed startup option `--database.remove-on-drop`
This option was used for debugging only.
* removed startup option `--database.force-sync-properties`
This option is now superfluous as collection properties are now stored in the
write-ahead log.
* introduced write-ahead log
All write operations in an ArangoDB server instance are automatically logged
to the server's write-ahead log. The write-ahead log is a set of append-only
logfiles, and it is used in case of a crash recovery and for replication.
Data from the write-ahead log will eventually be moved into the journals or
datafiles of collections, allowing the server to remove older write-ahead log
logfiles. Figures of collections will be updated when data are moved from the
write-ahead log into the journals or datafiles of collections.
Cross-collection transactions in ArangoDB should benefit considerably by this
change, as less writes than in previous versions are required to ensure the data
of multiple collections are atomcially and durably committed. All data-modifying
operations inside transactions (insert, update, remove) will write their
operations into the write-ahead log directly, making transactions with multiple
operations also require less physical memory than in previous versions of ArangoDB,
that required all transaction data to fit into RAM.
The `_trx` system collection is not used anymore in ArangoDB 2.2 and its usage is
discouraged.
The data in the write-ahead log can also be used in the replication context.
The `_replication` collection that was used in previous versions of ArangoDB to
store all changes on the server is not used anymore in ArangoDB 2.2. Instead,
slaves can read from a master's write-ahead log to get informed about most
recent changes. This removes the need to store data-modifying operations in
both the actual place and the `_replication` collection.
* removed startup option `--server.disable-replication-logger`
This option is superfluous in ArangoDB 2.2. There is no dedicated replication
logger in ArangoDB 2.2. There is now always the write-ahead log, and it is also
used as the server's replication log. Specifying the startup option
`--server.disable-replication-logger` will do nothing in ArangoDB 2.2, but the
option should not be used anymore as it might be removed in a future version.
* changed behavior of replication logger
There is no dedicated replication logger in ArangoDB 2.2 as there is the
write-ahead log now. The existing APIs for starting and stopping the replication
logger still exist in ArangoDB 2.2 for downwards-compatibility, but calling
the start or stop operations are no-ops in ArangoDB 2.2. When querying the
replication logger status via the API, the server will always report that the
replication logger is running. Configuring the replication logger is a no-op
in ArangoDB 2.2, too. Changing the replication logger configuration has no
effect. Instead, the write-ahead log configuration can be changed.
* removed MRuby integration for arangod
ArangoDB had an experimental MRuby integration in some of the publish builds.
This wasn't continuously developed, and so it has been removed in ArangoDB 2.2.
This change has led to the following startup options being superfluous:
- `--ruby.gc-interval`
- `--ruby.action-directory`
- `--ruby.modules-path`
- `--ruby.startup-directory`
Specifying these startup options will do nothing in ArangoDB 2.2, but the
options should be avoided from now on as they might be removed in future versions.
* reclaim index memory when last document in collection is deleted
Previously, deleting documents from a collection did not lead to index sizes being
reduced. Instead, the already allocated index memory was re-used when a collection
was refilled.
Now, index memory for primary indexes and hash indexes is reclaimed instantly when
the last document from a collection is removed.
* inlined and optimized functions in hash indexes
* added AQL TRANSLATE function
This function can be used to perform lookups from static lists, e.g.
LET countryNames = { US: "United States", UK: "United Kingdom", FR: "France" }
RETURN TRANSLATE("FR", countryNames)
* fixed datafile debugger
* fixed check-version for empty directory
* moved try/catch block to the top of routing chain
* added mountedApp function for foxx-manager
* fixed issue #883: arango 2.1 - when starting multi-machine cluster, UI web
does not change to cluster overview
* fixed dfdb: should not start any other V8 threads
* cleanup of version-check, added module org/arangodb/database-version,
added --check-version option
* fixed issue #881: [2.1.0] Bombarded (every 10 sec or so) with
"WARNING format string is corrupt" when in non-system DB Dashboard
* specialized primary index implementation to allow faster hash table
rebuilding and reduce lookups in datafiles for the actual value of `_key`.
* issue #862: added `--overwrite` option to arangoimp
* removed number of property lookups for documents during AQL queries that
access documents
* prevent buffering of long print results in arangosh's and arangod's print
command
this change will emit buffered intermediate print results and discard the
output buffer to quickly deliver print results to the user, and to prevent
constructing very large buffers for large results
* removed sorting of attribute names for use in a collection's shaper
sorting attribute names was done on document insert to keep attributes
of a collection in sorted order for faster comparisons. The sort order
of attributes was only used in one particular and unlikely case, so it
was removed. Collections with many different attribute names should
benefit from this change by faster inserts and slightly less memory usage.
* fixed a bug in arangodump which got the collection name in _from and _to
attributes of edges wrong (all were "_unknown")
* fixed a bug in arangorestore which did not recognise wrong _from and _to
attributes of edges
* improved error detection and reporting in arangorestore
-- ArangoDB Maintainer <info@arangodb.org> Fri, 11 Jul 2014 12:28:20 +0200
arangodb (2.2.0b3-1.1) stable; urgency=low
* Changed to Version 2.2.0-beta3
* honor startup option `--server.disable-statistics` when deciding whether or not
to start periodic statistics collection jobs
Previously, the statistics collection jobs were started even if the server was
started with the `--server.disable-statistics` flag being set to `true`
* removed startup option `--random.no-seed`
This option had no effect in previous versions of ArangoDB and was thus removed.
* removed startup option `--database.remove-on-drop`
* introduced write-ahead log
All write operations in an ArangoDB server instance are automatically logged
to the server's write-ahead log. The write-ahead log is a set of append-only
logfiles, and it is used in case of a crash recovery and for replication.
Data from the write-ahead log will eventually be moved into the datafiles of
collections, allowing the server to remove older write-ahead log logfiles.
Cross-collection transactions in ArangoDB should benefit considerably by this
change, as less writes than in previous versions is required to ensure the data
of multiple collections are atomcially and durably committed. All data-modifying
operations inside transactions (insert, update, remove) will write their
operations into the write-ahead log directly, making transactions with multiple
operations also require less physical memory than in previous versions of ArangoDB,
where most parts of transactions were handled in RAM first.
The data in the write-ahead log can also be used in the replication context.
The `_replication` collection that was used in previous versions of ArangoDB to
store all changes on the server is not used anymore in ArangoDB 2.2. Instead,
slaves can read from a master's write-ahead log to get informed about most
recent changes. This removes the need to store data-modifying operations in
both the actual place and the `_replication` collection.
Note: the replication from the write-ahead log is still in development.
* removed startup option `--server.disable-replication-logger`
This option is superfluous in ArangoDB 2.2. There is no dedicated replication
logger in ArangoDB 2.2. There is now always the write-ahead log, and it is also
used as the server's replication log. Specifying the startup option
`--server.disable-replication-logger` will do nothing in ArangoDB 2.2, but the
option should not be used anymore as it might be removed in a future version.
* changed behavior of replication logger
There is no dedicated replication logger in ArangoDB 2.2 as there is the
write-ahead log now. The existing APIs for starting and stopping the replication
logger still exist in ArangoDB 2.2 for downwards-compatibility, but calling
the start or stop operations are no-ops in ArangoDB 2.2. When querying the
replication logger status via the API, the server will always report that the
replication logger is running. Configuring the replication logger is a no-op
in ArangoDB 2.2, too. Changing the replication logger configuration has no
effect. Instead, the write-ahead log configuration can be changed.
* removed MRuby integration for arangod
ArangoDB had an experimental MRuby integration in some of the publish builds.
This wasn't continuously developed, and so it has been removed in ArangoDB 2.2.
This change has led to the following startup options being superfluous:
- `--ruby.gc-interval`
- `--ruby.action-directory`
- `--ruby.modules-path`
- `--ruby.startup-directory`
Specifying these startup options will do nothing in ArangoDB 2.2, but the
options should be avoided from now on as they might be removed in future versions.
* reclaim index memory when last document in collection is deleted
Previously, deleting documents from a collection did not lead to index sizes being
reduced. Instead, the already allocated index memory was re-used when a collection
was refilled.
Now, index memory for primary indexes and hash indexes is reclaimed instantly when
the last document from a collection is removed.
* inlined and optimized functions in hash indexes
* added AQL TRANSLATE function
This function can be used to perform lookups from static lists, e.g.
LET countryNames = { US: "United States", UK: "United Kingdom", FR: "France" }
RETURN TRANSLATE("FR", countryNames)
* fixed datafile debugger
* fixed check-version for empty directory
* moved try/catch block to the top of routing chain
* added mountedApp function for foxx-manager
* fixed issue #883: arango 2.1 - when starting multi-machine cluster, UI web
does not change to cluster overview
* fixed dfdb: should not start any other V8 threads
* cleanup of version-check, added module org/arangodb/database-version,
added --check-version option
* fixed issue #881: [2.1.0] Bombarded (every 10 sec or so) with
"WARNING format string is corrupt" when in non-system DB Dashboard
* specialized primary index implementation to allow faster hash table
rebuilding and reduce lookups in datafiles for the actual value of `_key`.
* issue #862: added `--overwrite` option to arangoimp
* removed number of property lookups for documents during AQL queries that
access documents
* prevent buffering of long print results in arangosh's and arangod's print
command
this change will emit buffered intermediate print results and discard the
output buffer to quickly deliver print results to the user, and to prevent
constructing very large buffers for large results
* removed sorting of attribute names for use in a collection's shaper
sorting attribute names was done on document insert to keep attributes
of a collection in sorted order for faster comparisons. The sort order
of attributes was only used in one particular and unlikely case, so it
was removed. Collections with many different attribute names should
benefit from this change by faster inserts and slightly less memory usage.
-- ArangoDB Maintainer <info@arangodb.org> Tue, 01 Jul 2014 18:30:19 +0200
arangodb (2.2.0b2-1.1) stable; urgency=low
* Changed to Version 2.2.0-beta2
* honor startup option `--server.disable-statistics` when deciding whether or not
to start periodic statistics collection jobs
Previously, the statistics collection jobs were started even if the server was
started with the `--server.disable-statistics` flag being set to `true`
* removed startup option `--random.no-seed`
This option had no effect in previous versions of ArangoDB and was thus removed.
* removed startup option `--database.remove-on-drop`
* introduced write-ahead log
All write operations in an ArangoDB server instance are automatically logged
to the server's write-ahead log. The write-ahead log is a set of append-only
logfiles, and it is used in case of a crash recovery and for replication.
Data from the write-ahead log will eventually be moved into the datafiles of
collections, allowing the server to remove older write-ahead log logfiles.
Cross-collection transactions in ArangoDB should benefit considerably by this
change, as less writes than in previous versions is required to ensure the data
of multiple collections are atomcially and durably committed. All data-modifying
operations inside transactions (insert, update, remove) will write their
operations into the write-ahead log directly, making transactions with multiple
operations also require less physical memory than in previous versions of ArangoDB,
where most parts of transactions were handled in RAM first.
The data in the write-ahead log can also be used in the replication context.
The `_replication` collection that was used in previous versions of ArangoDB to
store all changes on the server is not used anymore in ArangoDB 2.2. Instead,
slaves can read from a master's write-ahead log to get informed about most
recent changes. This removes the need to store data-modifying operations in
both the actual place and the `_replication` collection.
Note: the replication from the write-ahead log is still in development.
* removed startup option `--server.disable-replication-logger`
This option is superfluous in ArangoDB 2.2. There is no dedicated replication
logger in ArangoDB 2.2. There is now always the write-ahead log, and it is also
used as the server's replication log. Specifying the startup option
`--server.disable-replication-logger` will do nothing in ArangoDB 2.2, but the
option should not be used anymore as it might be removed in a future version.
* changed behavior of replication logger
There is no dedicated replication logger in ArangoDB 2.2 as there is the
write-ahead log now. The existing APIs for starting and stopping the replication
logger still exist in ArangoDB 2.2 for downwards-compatibility, but calling
the start or stop operations are no-ops in ArangoDB 2.2. When querying the
replication logger status via the API, the server will always report that the
replication logger is running. Configuring the replication logger is a no-op
in ArangoDB 2.2, too. Changing the replication logger configuration has no
effect. Instead, the write-ahead log configuration can be changed.
* removed MRuby integration for arangod
ArangoDB had an experimental MRuby integration in some of the publish builds.
This wasn't continuously developed, and so it has been removed in ArangoDB 2.2.
This change has led to the following startup options being superfluous:
- `--ruby.gc-interval`
- `--ruby.action-directory`
- `--ruby.modules-path`
- `--ruby.startup-directory`
Specifying these startup options will do nothing in ArangoDB 2.2, but the
options should be avoided from now on as they might be removed in future versions.
* reclaim index memory when last document in collection is deleted
Previously, deleting documents from a collection did not lead to index sizes being
reduced. Instead, the already allocated index memory was re-used when a collection
was refilled.
Now, index memory for primary indexes and hash indexes is reclaimed instantly when
the last document from a collection is removed.
* inlined and optimized functions in hash indexes
* added AQL TRANSLATE function
This function can be used to perform lookups from static lists, e.g.
LET countryNames = { US: "United States", UK: "United Kingdom", FR: "France" }
RETURN TRANSLATE("FR", countryNames)
* fixed datafile debugger
* fixed check-version for empty directory
* moved try/catch block to the top of routing chain
* added mountedApp function for foxx-manager
* fixed issue #883: arango 2.1 - when starting multi-machine cluster, UI web
does not change to cluster overview
* fixed dfdb: should not start any other V8 threads
* cleanup of version-check, added module org/arangodb/database-version,
added --check-version option
* fixed issue #881: [2.1.0] Bombarded (every 10 sec or so) with
"WARNING format string is corrupt" when in non-system DB Dashboard
* specialized primary index implementation to allow faster hash table
rebuilding and reduce lookups in datafiles for the actual value of `_key`.
* issue #862: added `--overwrite` option to arangoimp
* removed number of property lookups for documents during AQL queries that
access documents
* prevent buffering of long print results in arangosh's and arangod's print
command
this change will emit buffered intermediate print results and discard the
output buffer to quickly deliver print results to the user, and to prevent
constructing very large buffers for large results
* removed sorting of attribute names for use in a collection's shaper
sorting attribute names was done on document insert to keep attributes
of a collection in sorted order for faster comparisons. The sort order
of attributes was only used in one particular and unlikely case, so it
was removed. Collections with many different attribute names should
benefit from this change by faster inserts and slightly less memory usage.
-- ArangoDB Maintainer <info@arangodb.org> Tue, 01 Jul 2014 09:51:22 +0200
arangodb (2.2.0b1-1.1) stable; urgency=low
* Changed to Version 2.2.0-beta1
* honor startup option `--server.disable-statistics` when deciding whether or not
to start periodic statistics collection jobs
Previously, the statistics collection jobs were started even if the server was
started with the `--server.disable-statistics` flag being set to `true`
* removed startup option `--random.no-seed`
This option had no effect in previous versions of ArangoDB and was thus removed.
* removed startup option `--database.remove-on-drop`
* introduced write-ahead log
All write operations in an ArangoDB server instance are automatically logged
to the server's write-ahead log. The write-ahead log is a set of append-only
logfiles, and it is used in case of a crash recovery and for replication.
Data from the write-ahead log will eventually be moved into the datafiles of
collections, allowing the server to remove older write-ahead log logfiles.
Cross-collection transactions in ArangoDB should benefit considerably by this
change, as less writes than in previous versions is required to ensure the data
of multiple collections are atomcially and durably committed. All data-modifying
operations inside transactions (insert, update, remove) will write their
operations into the write-ahead log directly, making transactions with multiple
operations also require less physical memory than in previous versions of ArangoDB,
where most parts of transactions were handled in RAM first.
The data in the write-ahead log can also be used in the replication context.
The `_replication` collection that was used in previous versions of ArangoDB to
store all changes on the server is not used anymore in ArangoDB 2.2. Instead,
slaves can read from a master's write-ahead log to get informed about most
recent changes. This removes the need to store data-modifying operations in
both the actual place and the `_replication` collection.
Note: the replication from the write-ahead log is still in development.
* removed startup option `--server.disable-replication-logger`
This option is superfluous in ArangoDB 2.2. There is no dedicated replication
logger in ArangoDB 2.2. There is now always the write-ahead log, and it is also
used as the server's replication log. Specifying the startup option
`--server.disable-replication-logger` will do nothing in ArangoDB 2.2, but the
option should not be used anymore as it might be removed in a future version.
* changed behavior of replication logger
There is no dedicated replication logger in ArangoDB 2.2 as there is the
write-ahead log now. The existing APIs for starting and stopping the replication
logger still exist in ArangoDB 2.2 for downwards-compatibility, but calling
the start or stop operations are no-ops in ArangoDB 2.2. When querying the
replication logger status via the API, the server will always report that the
replication logger is running. Configuring the replication logger is a no-op
in ArangoDB 2.2, too. Changing the replication logger configuration has no
effect. Instead, the write-ahead log configuration can be changed.
* removed MRuby integration for arangod
ArangoDB had an experimental MRuby integration in some of the publish builds.
This wasn't continuously developed, and so it has been removed in ArangoDB 2.2.
This change has led to the following startup options being superfluous:
- `--ruby.gc-interval`
- `--ruby.action-directory`
- `--ruby.modules-path`
- `--ruby.startup-directory`
Specifying these startup options will do nothing in ArangoDB 2.2, but the
options should be avoided from now on as they might be removed in future versions.
* reclaim index memory when last document in collection is deleted
Previously, deleting documents from a collection did not lead to index sizes being
reduced. Instead, the already allocated index memory was re-used when a collection
was refilled.
Now, index memory for primary indexes and hash indexes is reclaimed instantly when
the last document from a collection is removed.
* inlined and optimized functions in hash indexes
* added AQL TRANSLATE function
This function can be used to perform lookups from static lists, e.g.
LET countryNames = { US: "United States", UK: "United Kingdom", FR: "France" }
RETURN TRANSLATE("FR", countryNames)
* fixed datafile debugger
* fixed check-version for empty directory
* moved try/catch block to the top of routing chain
* added mountedApp function for foxx-manager
* fixed issue #883: arango 2.1 - when starting multi-machine cluster, UI web
does not change to cluster overview
* fixed dfdb: should not start any other V8 threads
* cleanup of version-check, added module org/arangodb/database-version,
added --check-version option
* fixed issue #881: [2.1.0] Bombarded (every 10 sec or so) with
"WARNING format string is corrupt" when in non-system DB Dashboard
* specialized primary index implementation to allow faster hash table
rebuilding and reduce lookups in datafiles for the actual value of `_key`.
* issue #862: added `--overwrite` option to arangoimp
* removed number of property lookups for documents during AQL queries that
access documents
* prevent buffering of long print results in arangosh's and arangod's print
command
this change will emit buffered intermediate print results and discard the
output buffer to quickly deliver print results to the user, and to prevent
constructing very large buffers for large results
* removed sorting of attribute names for use in a collection's shaper
sorting attribute names was done on document insert to keep attributes
of a collection in sorted order for faster comparisons. The sort order
of attributes was only used in one particular and unlikely case, so it
was removed. Collections with many different attribute names should
benefit from this change by faster inserts and slightly less memory usage.
-- ArangoDB Maintainer <info@arangodb.org> Sat, 28 Jun 2014 10:34:22 +0200
arangodb (2.2.0a6-1.1) stable; urgency=low
* Changed to Version 2.2.0-alpha6
* honor startup option `--server.disable-statistics` when deciding whether or not
to start periodic statistics collection jobs
Previously, the statistics collection jobs were started even if the server was
started with the `--server.disable-statistics` flag being set to `true`
* removed startup option `--random.no-seed`
This option had no effect in previous versions of ArangoDB and was thus removed.
* removed startup option `--database.remove-on-drop`
* introduced write-ahead log
All write operations in an ArangoDB server instance are automatically logged
to the server's write-ahead log. The write-ahead log is a set of append-only
logfiles, and it is used in case of a crash recovery and for replication.
Data from the write-ahead log will eventually be moved into the datafiles of
collections, allowing the server to remove older write-ahead log logfiles.
Cross-collection transactions in ArangoDB should benefit considerably by this
change, as less writes than in previous versions is required to ensure the data
of multiple collections are atomcially and durably committed. All data-modifying
operations inside transactions (insert, update, remove) will write their
operations into the write-ahead log directly, making transactions with multiple
operations also require less physical memory than in previous versions of ArangoDB,
where most parts of transactions were handled in RAM first.
The data in the write-ahead log can also be used in the replication context.
The `_replication` collection that was used in previous versions of ArangoDB to
store all changes on the server is not used anymore in ArangoDB 2.2. Instead,
slaves can read from a master's write-ahead log to get informed about most
recent changes. This removes the need to store data-modifying operations in
both the actual place and the `_replication` collection.
Note: the replication from the write-ahead log is still in development.
* removed startup option `--server.disable-replication-logger`
This option is superfluous in ArangoDB 2.2. There is no dedicated replication
logger in ArangoDB 2.2. There is now always the write-ahead log, and it is also
used as the server's replication log. Specifying the startup option
`--server.disable-replication-logger` will do nothing in ArangoDB 2.2, but the
option should not be used anymore as it might be removed in a future version.
* changed behavior of replication logger
There is no dedicated replication logger in ArangoDB 2.2 as there is the
write-ahead log now. The existing APIs for starting and stopping the replication
logger still exist in ArangoDB 2.2 for downwards-compatibility, but calling
the start or stop operations are no-ops in ArangoDB 2.2. When querying the
replication logger status via the API, the server will always report that the
replication logger is running. Configuring the replication logger is a no-op
in ArangoDB 2.2, too. Changing the replication logger configuration has no
effect. Instead, the write-ahead log configuration can be changed.
* removed MRuby integration for arangod
ArangoDB had an experimental MRuby integration in some of the publish builds.
This wasn't continuously developed, and so it has been removed in ArangoDB 2.2.
This change has led to the following startup options being superfluous:
- `--ruby.gc-interval`
- `--ruby.action-directory`
- `--ruby.modules-path`
- `--ruby.startup-directory`
Specifying these startup options will do nothing in ArangoDB 2.2, but the
options should be avoided from now on as they might be removed in future versions.
* reclaim index memory when last document in collection is deleted
Previously, deleting documents from a collection did not lead to index sizes being
reduced. Instead, the already allocated index memory was re-used when a collection
was refilled.
Now, index memory for primary indexes and hash indexes is reclaimed instantly when
the last document from a collection is removed.
* inlined and optimized functions in hash indexes
* added AQL TRANSLATE function
This function can be used to perform lookups from static lists, e.g.
LET countryNames = { US: "United States", UK: "United Kingdom", FR: "France" }
RETURN TRANSLATE("FR", countryNames)
* fixed datafile debugger
* fixed check-version for empty directory
* moved try/catch block to the top of routing chain
* added mountedApp function for foxx-manager
* fixed issue #883: arango 2.1 - when starting multi-machine cluster, UI web
does not change to cluster overview
* fixed dfdb: should not start any other V8 threads
* cleanup of version-check, added module org/arangodb/database-version,
added --check-version option
* fixed issue #881: [2.1.0] Bombarded (every 10 sec or so) with
"WARNING format string is corrupt" when in non-system DB Dashboard
* specialized primary index implementation to allow faster hash table
rebuilding and reduce lookups in datafiles for the actual value of `_key`.
* issue #862: added `--overwrite` option to arangoimp
* removed number of property lookups for documents during AQL queries that
access documents
* prevent buffering of long print results in arangosh's and arangod's print
command
this change will emit buffered intermediate print results and discard the
output buffer to quickly deliver print results to the user, and to prevent
constructing very large buffers for large results
* removed sorting of attribute names for use in a collection's shaper
sorting attribute names was done on document insert to keep attributes
of a collection in sorted order for faster comparisons. The sort order
of attributes was only used in one particular and unlikely case, so it
was removed. Collections with many different attribute names should
benefit from this change by faster inserts and slightly less memory usage.
-- ArangoDB Maintainer <info@arangodb.org> Fri, 27 Jun 2014 11:33:12 +0200
arangodb (2.2.0a4-1.1) stable; urgency=low
* Changed to Version 2.2.0-alpha4
* honor startup option `--server.disable-statistics` when deciding whether or not
to start periodic statistics collection jobs
Previously, the statistics collection jobs were started even if the server was
started with the `--server.disable-statistics` flag being set to `true`
* removed startup option `--random.no-seed`
This option had no effect in previous versions of ArangoDB and was thus removed.
* removed startup option `--database.remove-on-drop`
* introduced write-ahead log
All write operations in an ArangoDB server instance are automatically logged
to the server's write-ahead log. The write-ahead log is a set of append-only
logfiles, and it is used in case of a crash recovery and for replication.
Data from the write-ahead log will eventually be moved into the datafiles of
collections, allowing the server to remove older write-ahead log logfiles.
Cross-collection transactions in ArangoDB should benefit considerably by this
change, as less writes than in previous versions is required to ensure the data
of multiple collections are atomcially and durably committed. All data-modifying
operations inside transactions (insert, update, remove) will write their
operations into the write-ahead log directly, making transactions with multiple
operations also require less physical memory than in previous versions of ArangoDB,
where most parts of transactions were handled in RAM first.
The data in the write-ahead log can also be used in the replication context.
The `_replication` collection that was used in previous versions of ArangoDB to
store all changes on the server is not used anymore in ArangoDB 2.2. Instead,
slaves can read from a master's write-ahead log to get informed about most
recent changes. This removes the need to store data-modifying operations in
both the actual place and the `_replication` collection.
Note: the replication from the write-ahead log is still in development.
* removed startup option `--server.disable-replication-logger`
This option is superfluous in ArangoDB 2.2. There is no dedicated replication
logger in ArangoDB 2.2. There is now always the write-ahead log, and it is also
used as the server's replication log. Specifying the startup option
`--server.disable-replication-logger` will do nothing in ArangoDB 2.2, but the
option should not be used anymore as it might be removed in a future version.
* changed behavior of replication logger
There is no dedicated replication logger in ArangoDB 2.2 as there is the
write-ahead log now. The existing APIs for starting and stopping the replication
logger still exist in ArangoDB 2.2 for downwards-compatibility, but calling
the start or stop operations are no-ops in ArangoDB 2.2. When querying the
replication logger status via the API, the server will always report that the
replication logger is running. Configuring the replication logger is a no-op
in ArangoDB 2.2, too. Changing the replication logger configuration has no
effect. Instead, the write-ahead log configuration can be changed.
* removed MRuby integration for arangod
ArangoDB had an experimental MRuby integration in some of the publish builds.
This wasn't continuously developed, and so it has been removed in ArangoDB 2.2.
This change has led to the following startup options being superfluous:
- `--ruby.gc-interval`
- `--ruby.action-directory`
- `--ruby.modules-path`
- `--ruby.startup-directory`
Specifying these startup options will do nothing in ArangoDB 2.2, but the
options should be avoided from now on as they might be removed in future versions.
* reclaim index memory when last document in collection is deleted
Previously, deleting documents from a collection did not lead to index sizes being
reduced. Instead, the already allocated index memory was re-used when a collection
was refilled.
Now, index memory for primary indexes and hash indexes is reclaimed instantly when
the last document from a collection is removed.
* inlined and optimized functions in hash indexes
* added AQL TRANSLATE function
This function can be used to perform lookups from static lists, e.g.
LET countryNames = { US: "United States", UK: "United Kingdom", FR: "France" }
RETURN TRANSLATE("FR", countryNames)
* fixed datafile debugger
* fixed check-version for empty directory
* moved try/catch block to the top of routing chain
* added mountedApp function for foxx-manager
* fixed issue #883: arango 2.1 - when starting multi-machine cluster, UI web
does not change to cluster overview
* fixed dfdb: should not start any other V8 threads
* cleanup of version-check, added module org/arangodb/database-version,
added --check-version option
* fixed issue #881: [2.1.0] Bombarded (every 10 sec or so) with
"WARNING format string is corrupt" when in non-system DB Dashboard
* specialized primary index implementation to allow faster hash table
rebuilding and reduce lookups in datafiles for the actual value of `_key`.
* issue #862: added `--overwrite` option to arangoimp
* removed number of property lookups for documents during AQL queries that
access documents
* prevent buffering of long print results in arangosh's and arangod's print
command
this change will emit buffered intermediate print results and discard the
output buffer to quickly deliver print results to the user, and to prevent
constructing very large buffers for large results
* removed sorting of attribute names for use in a collection's shaper
sorting attribute names was done on document insert to keep attributes
of a collection in sorted order for faster comparisons. The sort order
of attributes was only used in one particular and unlikely case, so it
was removed. Collections with many different attribute names should
benefit from this change by faster inserts and slightly less memory usage.
-- ArangoDB Maintainer <info@arangodb.org> Wed, 25 Jun 2014 23:56:02 +0200
arangodb (2.2.0a2-1.1) stable; urgency=low
* Changed to Version 2.2.0-alpha2
* introduced write-ahead log
All write operations in an ArangoDB server instance are automatically logged
to the server's write-ahead log. The write-ahead log is a set of append-only
logfiles, and it is used in case of a crash recovery and for replication.
Data from the write-ahead log will eventually be moved into the datafiles of
collections, allowing the server to remove older write-ahead log logfiles.
Cross-collection transactions in ArangoDB should benefit considerably by this
change, as less writes than in previous versions is required to ensure the data
of multiple collections are atomcially and durably committed. All data-modifying
operations inside transactions (insert, update, remove) will write their
operations into the write-ahead log directly, making transactions with multiple
operations also require less physical memory than in previous versions of ArangoDB,
where most parts of transactions were handled in RAM first.
The data in the write-ahead log can also be used in the replication context.
The `_replication` collection that was used in previous versions of ArangoDB to
store all changes on the server is not used anymore in ArangoDB 2.2. Instead,
slaves can read from a master's write-ahead log to get informed about most
recent changes. This removes the need to store data-modifying operations in
both the actual place and the `_replication` collection.
Note: the replication from the write-ahead log is still in development.
* removed startup option `--server.disable-replication-logger`
This option is superfluous in ArangoDB 2.2. There is no dedicated replication
logger in ArangoDB 2.2. There is now always the write-ahead log, and it is also
used as the server's replication log. Specifying the startup option
`--server.disable-replication-logger` will do nothing in ArangoDB 2.2, but the
option should not be used anymore as it might be removed in a future version.
* changed behavior of replication logger
There is no dedicated replication logger in ArangoDB 2.2 as there is the
write-ahead log now. The existing APIs for starting and stopping the replication
logger still exist in ArangoDB 2.2 for downwards-compatibility, but calling
the start or stop operations are no-ops in ArangoDB 2.2. When querying the
replication logger status via the API, the server will always report that the
replication logger is running. Configuring the replication logger is a no-op
in ArangoDB 2.2, too. Changing the replication logger configuration has no
effect. Instead, the write-ahead log configuration can be changed.
* removed MRuby integration for arangod
ArangoDB had an experimental MRuby integration in some of the publish builds.
This wasn't continuously developed, and so it has been removed in ArangoDB 2.2.
This change has led to the following startup options being superfluous:
- `--ruby.gc-interval`
- `--ruby.action-directory`
- `--ruby.modules-path`
- `--ruby.startup-directory`
Specifying these startup options will do nothing in ArangoDB 2.2, but the
options should be avoided from now on as they might be removed in future versions.
* reclaim index memory when last document in collection is deleted
Previously, deleting documents from a collection did not lead to index sizes being
reduced. Instead, the already allocated index memory was re-used when a collection
was refilled.
Now, index memory for primary indexes and hash indexes is reclaimed instantly when
the last document from a collection is removed.
* inlined and optimized functions in hash indexes
* added AQL TRANSLATE function
This function can be used to perform lookups from static lists, e.g.
LET countryNames = { US: "United States", UK: "United Kingdom", FR: "France" }
RETURN TRANSLATE("FR", countryNames)
* fixed datafile debugger
* fixed check-version for empty directory
* moved try/catch block to the top of routing chain
* added mountedApp function for foxx-manager
* fixed issue #883: arango 2.1 - when starting multi-machine cluster, UI web
does not change to cluster overview
* fixed dfdb: should not start any other V8 threads
* cleanup of version-check, added module org/arangodb/database-version,
added --check-version option
* fixed issue #881: [2.1.0] Bombarded (every 10 sec or so) with
"WARNING format string is corrupt" when in non-system DB Dashboard
* specialized primary index implementation to allow faster hash table
rebuilding and reduce lookups in datafiles for the actual value of `_key`.
* issue #862: added `--overwrite` option to arangoimp
* removed number of property lookups for documents during AQL queries that
access documents
* prevent buffering of long print results in arangosh's and arangod's print
command
this change will emit buffered intermediate print results and discard the
output buffer to quickly deliver print results to the user, and to prevent
constructing very large buffers for large results
* removed sorting of attribute names for use in a collection's shaper
sorting attribute names was done on document insert to keep attributes
of a collection in sorted order for faster comparisons. The sort order
of attributes was only used in one particular and unlikely case, so it
was removed. Collections with many different attribute names should
benefit from this change by faster inserts and slightly less memory usage.
-- ArangoDB Maintainer <info@arangodb.org> Mon, 23 Jun 2014 16:43:29 +0200
arangodb (2.2.0a1-1.1) stable; urgency=low
* Changed to Version 2.2.0-alpha1
* introduced write-ahead log
All write operations in an ArangoDB server instance are automatically logged
to the server's write-ahead log. The write-ahead log is a set of append-only
logfiles, and it is used in case of a crash recovery and for replication.
Data from the write-ahead log will eventually be moved into the datafiles of
collections, allowing the server to remove older write-ahead log logfiles.
Cross-collection transactions in ArangoDB should benefit considerably by this
change, as less writes than in previous versions is required to ensure the data
of multiple collections are atomcially and durably committed. All data-modifying
operations inside transactions (insert, update, remove) will write their
operations into the write-ahead log directly, making transactions with multiple
operations also require less physical memory than in previous versions of ArangoDB,
where most parts of transactions were handled in RAM first.
The data in the write-ahead log can also be used in the replication context.
The `_replication` collection that was used in previous versions of ArangoDB to
store all changes on the server is not used anymore in ArangoDB 2.2. Instead,
slaves can read from a master's write-ahead log to get informed about most
recent changes. This removes the need to store data-modifying operations in
both the actual place and the `_replication` collection.
Note: the replication from the write-ahead log is still in development.
* removed startup option `--server.disable-replication-logger`
This option is superfluous in ArangoDB 2.2. There is no dedicated replication
logger in ArangoDB 2.2. There is now always the write-ahead log, and it is also
used as the server's replication log. Specifying the startup option
`--server.disable-replication-logger` will do nothing in ArangoDB 2.2, but the
option should not be used anymore as it might be removed in a future version.
* changed behavior of replication logger
There is no dedicated replication logger in ArangoDB 2.2 as there is the
write-ahead log now. The existing APIs for starting and stopping the replication
logger still exist in ArangoDB 2.2 for downwards-compatibility, but calling
the start or stop operations are no-ops in ArangoDB 2.2. When querying the
replication logger status via the API, the server will always report that the
replication logger is running. Configuring the replication logger is a no-op
in ArangoDB 2.2, too. Changing the replication logger configuration has no
effect. Instead, the write-ahead log configuration can be changed.
* removed MRuby integration for arangod
ArangoDB had an experimental MRuby integration in some of the publish builds.
This wasn't continuously developed, and so it has been removed in ArangoDB 2.2.
This change has led to the following startup options being superfluous:
- `--ruby.gc-interval`
- `--ruby.action-directory`
- `--ruby.modules-path`
- `--ruby.startup-directory`
Specifying these startup options will do nothing in ArangoDB 2.2, but the
options should be avoided from now on as they might be removed in future versions.
* reclaim index memory when last document in collection is deleted
Previously, deleting documents from a collection did not lead to index sizes being
reduced. Instead, the already allocated index memory was re-used when a collection
was refilled.
Now, index memory for primary indexes and hash indexes is reclaimed instantly when
the last document from a collection is removed.
* inlined and optimized functions in hash indexes
* added AQL TRANSLATE function
This function can be used to perform lookups from static lists, e.g.
LET countryNames = { US: "United States", UK: "United Kingdom", FR: "France" }
RETURN TRANSLATE("FR", countryNames)
* fixed datafile debugger
* fixed check-version for empty directory
* moved try/catch block to the top of routing chain
* added mountedApp function for foxx-manager
* fixed issue #883: arango 2.1 - when starting multi-machine cluster, UI web
does not change to cluster overview
* fixed dfdb: should not start any other V8 threads
* cleanup of version-check, added module org/arangodb/database-version,
added --check-version option
* fixed issue #881: [2.1.0] Bombarded (every 10 sec or so) with
"WARNING format string is corrupt" when in non-system DB Dashboard
* specialized primary index implementation to allow faster hash table
rebuilding and reduce lookups in datafiles for the actual value of `_key`.
* issue #862: added `--overwrite` option to arangoimp
* removed number of property lookups for documents during AQL queries that
access documents
* prevent buffering of long print results in arangosh's and arangod's print
command
this change will emit buffered intermediate print results and discard the
output buffer to quickly deliver print results to the user, and to prevent
constructing very large buffers for large results
* removed sorting of attribute names for use in a collection's shaper
sorting attribute names was done on document insert to keep attributes
of a collection in sorted order for faster comparisons. The sort order
of attributes was only used in one particular and unlikely case, so it
was removed. Collections with many different attribute names should
benefit from this change by faster inserts and slightly less memory usage.
-- ArangoDB Maintainer <info@arangodb.org> Mon, 23 Jun 2014 11:46:12 +0200
arangodb (2.1.2-1.1) stable; urgency=low
* Changed to Version 2.1.2
* fixed check-version for empty directory
* moved try/catch block to the top of routing chain
-- ArangoDB Maintainer <info@arangodb.org> Sun, 15 Jun 2014 16:05:00 +0200
arangodb (2.1.1-1.1) stable; urgency=low
* Changed to Version 2.1.1
* fixed random generation under MacOSX
* fixed issue #883: arango 2.1 - when starting multi-machine cluster, UI web
does not change to cluster overview
* fixed dfdb: should not start any other V8 threads
* cleanup of version-check, added module org/arangodb/database-version,
added --check-version option
* fixed issue #881: [2.1.0] Bombarded (every 10 sec or so) with
"WARNING format string is corrupt" when in non-system DB Dashboard
-- ArangoDB Maintainer <info@arangodb.org> Fri, 06 Jun 2014 18:41:30 +0200
-- ArangoDB Maintainer <info@arangodb.org> Sun, 01 Jun 2014 22:10:48 +0200
arangodb (2.1.0-1.1) stable; urgency=low
* Changed to Version 2.1.0
* implemented upgrade procedure for clusters
* fixed communication issue with agency which prevented reconnect
after an agent failure
* fixed cluster dashboard in the case that one but not all servers
in the cluster are down
* fixed a bug with coordinators creating local database objects
in the wrong order (_system needs to be done successfully first),
which lead to a coordinator on strike
* improved cluster dashboard
-- ArangoDB Maintainer <info@arangodb.org> Thu, 29 May 2014 11:01:03 +0200
arangodb (2.1.0r2-1.1) stable; urgency=low
* Changed to Version 2.1.0-rc2
* fixed issue #864: Inconsistent behavior of AQL REVERSE(list) function
-- ArangoDB Maintainer <info@arangodb.org> Mon, 26 May 2014 00:48:13 +0200
arangodb (2.1.0r1-1.1) stable; urgency=low
* Changed to Version 2.1.0-rc1
* added server-side periodic task management functions:
- require("org/arangodb/tasks").register(): registers a periodic task
- require("org/arangodb/tasks").unregister(): unregisters and removes a
periodic task
- require("org/arangodb/tasks").get(): retrieves a specific tasks or all
existing tasks
the previous undocumented function `internal.definePeriodic` is now
deprecated and will be removed in a future release.
* decrease the size of some seldomly used system collections on creation.
This will make these collections use less disk space and mapped memory.
* added AQL date functions
* added AQL FLATTEN() and FLATTEN_RECURSIVE() list functions
* added index memory statistics to `db.<collection>.figures()` function
The `figures` function will now return a sub-document `indexes`, which lists
the number of indexes in the `count` sub-attribute, and the total memory
usage of the indexes in bytes in the `size` sub-attribute.
* added AQL CURRENT_DATABASE() function
This function returns the current database's name.
* added AQL CURRENT_USER() function
This function returns the current user from an AQL query. The current user is the
username that was specified in the `Authorization` HTTP header of the request. If
authentication is turned off or the query was executed outside a request context,
the function will return `null`.
* fixed issue #796: Searching with newline chars broken?
fixed slightly different handling of backslash escape characters in a few
AQL functions. Now handling of escape sequences should be consistent, and
searching for newline characters should work the same everywhere
* added OpenSSL version check for configure
It will report all OpenSSL versions < 1.0.1g as being too old.
`configure` will only complain about an outdated OpenSSL version but not stop.
* require C++ compiler support (requires g++ 4.8, clang++ 3.4 or Visual Studio 13)
* less string copying returning JSONified documents from ArangoDB, e.g. via
HTTP GET `/_api/document/<collection>/<document>`
* issue #798: Lower case http headers from arango
This change allows returning capitalized HTTP headers, e.g.
`Content-Length` instead of `content-length`.
The HTTP spec says that headers are case-insensitive, but
in fact several clients rely on a specific case in response
headers.
This change will capitalize HTTP headers if the `X-Arango-Version`
request header is sent by the client and contains a value of at
least `20100` (for version 2.1). The default value for the
compatibility can also be set at server start, using the
`--server.default-api-compatibility` option.
* simplified usage of `db._createStatement()`
Previously, the function could not be called with a query string parameter as
follows:
db._createStatement(queryString);
Calling it as above resulted in an error because the function expected an
object as its parameter. From now on, it's possible to call the function with
just the query string.
* make ArangoDB not send back a `WWW-Authenticate` header to a client in case the
client sends the `X-Omit-WWW-Authenticate` HTTP header.
This is done to prevent browsers from showing their built-in HTTP authentication
dialog for AJAX requests that require authentication.
ArangoDB will still return an HTTP 401 (Unauthorized) if the request doesn't
contain valid credentials, but it will omit the `WWW-Authenticate` header,
allowing clients to bypass the browser's authentication dialog.
* added REST API method HTTP GET `/_api/job/job-id` to query the status of an
async job without potentially fetching it from the list of done jobs
* fixed non-intuitive behavior in jobs API: previously, querying the status
of an async job via the API HTTP PUT `/_api/job/job-id` removed a currently
executing async job from the list of queryable jobs on the server.
Now, when querying the result of an async job that is still executing,
the job is kept in the list of queryable jobs so its result can be fetched
by a subsequent request.
* use a new data structure for the edge index of an edge collection. This
improves the performance for the creation of the edge index and in
particular speeds up removal of edges in graphs. Note however that
this change might change the order in which edges starting at
or ending in a vertex are returned. However, this order was never
guaranteed anyway and it is not sensible to guarantee any particular
order.
* provide a size hint to edge and hash indexes when initially filling them
this will lead to less re-allocations when populating these indexes
this may speed up building indexes when opening an existing collection
* don't requeue identical context methods in V8 threads in case a method is
already registered
* removed arangod command line option `--database.remove-on-compacted`
* export the sort attribute for graph traversals to the HTTP interface
* add support for arangodump/arangorestore for clusters
-- ArangoDB Maintainer <info@arangodb.org> Mon, 12 May 2014 19:29:58 +0200
arangodb (2.1.0a9-1.1) stable; urgency=low
* Changed to Version 2.1.0-alpha9
* added server-side periodic task management functions:
- require("org/arangodb/tasks").register(): registers a periodic task
- require("org/arangodb/tasks").unregister(): unregisters and removes a
periodic task
- require("org/arangodb/tasks").get(): retrieves a specific tasks or all
existing tasks
the previous undocumented function `internal.definePeriodic` is now
deprecated and will be removed in a future release.
* decrease the size of some seldomly used system collections on creation.
This will make these collections use less disk space and mapped memory.
* added AQL date functions
* added AQL FLATTEN() and FLATTEN_RECURSIVE() list functions
* added index memory statistics to `db.<collection>.figures()` function
The `figures` function will now return a sub-document `indexes`, which lists
the number of indexes in the `count` sub-attribute, and the total memory
usage of the indexes in bytes in the `size` sub-attribute.
* added AQL CURRENT_DATABASE() function
This function returns the current database's name.
* added AQL CURRENT_USER() function
This function returns the current user from an AQL query. The current user is the
username that was specified in the `Authorization` HTTP header of the request. If
authentication is turned off or the query was executed outside a request context,
the function will return `null`.
* fixed issue #796: Searching with newline chars broken?
fixed slightly different handling of backslash escape characters in a few
AQL functions. Now handling of escape sequences should be consistent, and
searching for newline characters should work the same everywhere
* added OpenSSL version check for configure
It will report all OpenSSL versions < 1.0.1g as being too old.
`configure` will only complain about an outdated OpenSSL version but not stop.
* require C++ compiler support (requires g++ 4.8, clang++ 3.4 or Visual Studio 13)
* less string copying returning JSONified documents from ArangoDB, e.g. via
HTTP GET `/_api/document/<collection>/<document>`
* issue #798: Lower case http headers from arango
This change allows returning capitalized HTTP headers, e.g.
`Content-Length` instead of `content-length`.
The HTTP spec says that headers are case-insensitive, but
in fact several clients rely on a specific case in response
headers.
This change will capitalize HTTP headers if the `X-Arango-Version`
request header is sent by the client and contains a value of at
least `20100` (for version 2.1). The default value for the
compatibility can also be set at server start, using the
`--server.default-api-compatibility` option.
* simplified usage of `db._createStatement()`
Previously, the function could not be called with a query string parameter as
follows:
db._createStatement(queryString);
Calling it as above resulted in an error because the function expected an
object as its parameter. From now on, it's possible to call the function with
just the query string.
* make ArangoDB not send back a `WWW-Authenticate` header to a client in case the
client sends the `X-Omit-WWW-Authenticate` HTTP header.
This is done to prevent browsers from showing their built-in HTTP authentication
dialog for AJAX requests that require authentication.
ArangoDB will still return an HTTP 401 (Unauthorized) if the request doesn't
contain valid credentials, but it will omit the `WWW-Authenticate` header,
allowing clients to bypass the browser's authentication dialog.
* added REST API method HTTP GET `/_api/job/job-id` to query the status of an
async job without potentially fetching it from the list of done jobs
* fixed non-intuitive behavior in jobs API: previously, querying the status
of an async job via the API HTTP PUT `/_api/job/job-id` removed a currently
executing async job from the list of queryable jobs on the server.
Now, when querying the result of an async job that is still executing,
the job is kept in the list of queryable jobs so its result can be fetched
by a subsequent request.
* use a new data structure for the edge index of an edge collection. This
improves the performance for the creation of the edge index and in
particular speeds up removal of edges in graphs. Note however that
this change might change the order in which edges starting at
or ending in a vertex are returned. However, this order was never
guaranteed anyway and it is not sensible to guarantee any particular
order.
* provide a size hint to edge and hash indexes when initially filling them
this will lead to less re-allocations when populating these indexes
this may speed up building indexes when opening an existing collection
* don't requeue identical context methods in V8 threads in case a method is
already registered
* removed arangod command line option `--database.remove-on-compacted`
* export the sort attribute for graph traversals to the HTTP interface
* add support for arangodump/arangorestore for clusters
-- ArangoDB Maintainer <info@arangodb.org> Sun, 11 May 2014 01:13:36 +0200
arangodb (2.1.0a7-1.1) stable; urgency=low
* Changed to Version 2.1.0-alpha7
* added server-side periodic task management functions:
- require("org/arangodb/tasks").register(): registers a periodic task
- require("org/arangodb/tasks").unregister(): unregisters and removes a
periodic task
- require("org/arangodb/tasks").get(): retrieves a specific tasks or all
existing tasks
the previous undocumented function `internal.definePeriodic` is now
deprecated and will be removed in a future release.
* decrease the size of some seldomly used system collections on creation.
This will make these collections use less disk space and mapped memory.
* added AQL date functions
* added AQL FLATTEN() and FLATTEN_RECURSIVE() list functions
* added index memory statistics to `db.<collection>.figures()` function
The `figures` function will now return a sub-document `indexes`, which lists
the number of indexes in the `count` sub-attribute, and the total memory
usage of the indexes in bytes in the `size` sub-attribute.
* added AQL CURRENT_DATABASE() function
This function returns the current database's name.
* added AQL CURRENT_USER() function
This function returns the current user from an AQL query. The current user is the
username that was specified in the `Authorization` HTTP header of the request. If
authentication is turned off or the query was executed outside a request context,
the function will return `null`.
* fixed issue #796: Searching with newline chars broken?
fixed slightly different handling of backslash escape characters in a few
AQL functions. Now handling of escape sequences should be consistent, and
searching for newline characters should work the same everywhere
* added OpenSSL version check for configure
It will report all OpenSSL versions < 1.0.1g as being too old.
`configure` will only complain about an outdated OpenSSL version but not stop.
* require C++ compiler support (requires g++ 4.8, clang++ 3.4 or Visual Studio 13)
* less string copying returning JSONified documents from ArangoDB, e.g. via
HTTP GET `/_api/document/<collection>/<document>`
* issue #798: Lower case http headers from arango
This change allows returning capitalized HTTP headers, e.g.
`Content-Length` instead of `content-length`.
The HTTP spec says that headers are case-insensitive, but
in fact several clients rely on a specific case in response
headers.
This change will capitalize HTTP headers if the `X-Arango-Version`
request header is sent by the client and contains a value of at
least `20100` (for version 2.1). The default value for the
compatibility can also be set at server start, using the
`--server.default-api-compatibility` option.
* simplified usage of `db._createStatement()`
Previously, the function could not be called with a query string parameter as
follows:
db._createStatement(queryString);
Calling it as above resulted in an error because the function expected an
object as its parameter. From now on, it's possible to call the function with
just the query string.
* make ArangoDB not send back a `WWW-Authenticate` header to a client in case the
client sends the `X-Omit-WWW-Authenticate` HTTP header.
This is done to prevent browsers from showing their built-in HTTP authentication
dialog for AJAX requests that require authentication.
ArangoDB will still return an HTTP 401 (Unauthorized) if the request doesn't
contain valid credentials, but it will omit the `WWW-Authenticate` header,
allowing clients to bypass the browser's authentication dialog.
* added REST API method HTTP GET `/_api/job/job-id` to query the status of an
async job without potentially fetching it from the list of done jobs
* fixed non-intuitive behavior in jobs API: previously, querying the status
of an async job via the API HTTP PUT `/_api/job/job-id` removed a currently
executing async job from the list of queryable jobs on the server.
Now, when querying the result of an async job that is still executing,
the job is kept in the list of queryable jobs so its result can be fetched
by a subsequent request.
* use a new data structure for the edge index of an edge collection. This
improves the performance for the creation of the edge index and in
particular speeds up removal of edges in graphs. Note however that
this change might change the order in which edges starting at
or ending in a vertex are returned. However, this order was never
guaranteed anyway and it is not sensible to guarantee any particular
order.
* provide a size hint to edge and hash indexes when initially filling them
this will lead to less re-allocations when populating these indexes
this may speed up building indexes when opening an existing collection
* don't requeue identical context methods in V8 threads in case a method is
already registered
* removed arangod command line option `--database.remove-on-compacted`
* export the sort attribute for graph traversals to the HTTP interface
* add support for arangodump/arangorestore for clusters
-- ArangoDB Maintainer <info@arangodb.org> Sat, 10 May 2014 20:05:38 +0200
arangodb (2.1.0a6-1.1) stable; urgency=low
* Changed to Version 2.1.0-alpha6
* added server-side periodic task management functions:
- require("org/arangodb/tasks").register(): registers a periodic task
- require("org/arangodb/tasks").unregister(): unregisters and removes a
periodic task
- require("org/arangodb/tasks").get(): retrieves a specific tasks or all
existing tasks
the previous undocumented function `internal.definePeriodic` is now
deprecated and will be removed in a future release.
* decrease the size of some seldomly used system collections on creation.
This will make these collections use less disk space and mapped memory.
* added AQL date functions
* added AQL FLATTEN() and FLATTEN_RECURSIVE() list functions
* added index memory statistics to `db.<collection>.figures()` function
The `figures` function will now return a sub-document `indexes`, which lists
the number of indexes in the `count` sub-attribute, and the total memory
usage of the indexes in bytes in the `size` sub-attribute.
* added AQL CURRENT_DATABASE() function
This function returns the current database's name.
* added AQL CURRENT_USER() function
This function returns the current user from an AQL query. The current user is the
username that was specified in the `Authorization` HTTP header of the request. If
authentication is turned off or the query was executed outside a request context,
the function will return `null`.
* fixed issue #796: Searching with newline chars broken?
fixed slightly different handling of backslash escape characters in a few
AQL functions. Now handling of escape sequences should be consistent, and
searching for newline characters should work the same everywhere
* added OpenSSL version check for configure
It will report all OpenSSL versions < 1.0.1g as being too old.
`configure` will only complain about an outdated OpenSSL version but not stop.
* require C++ compiler support (requires g++ 4.8, clang++ 3.4 or Visual Studio 13)
* less string copying returning JSONified documents from ArangoDB, e.g. via
HTTP GET `/_api/document/<collection>/<document>`
* issue #798: Lower case http headers from arango
This change allows returning capitalized HTTP headers, e.g.
`Content-Length` instead of `content-length`.
The HTTP spec says that headers are case-insensitive, but
in fact several clients rely on a specific case in response
headers.
This change will capitalize HTTP headers if the `X-Arango-Version`
request header is sent by the client and contains a value of at
least `20100` (for version 2.1). The default value for the
compatibility can also be set at server start, using the
`--server.default-api-compatibility` option.
* simplified usage of `db._createStatement()`
Previously, the function could not be called with a query string parameter as
follows:
db._createStatement(queryString);
Calling it as above resulted in an error because the function expected an
object as its parameter. From now on, it's possible to call the function with
just the query string.
* make ArangoDB not send back a `WWW-Authenticate` header to a client in case the
client sends the `X-Omit-WWW-Authenticate` HTTP header.
This is done to prevent browsers from showing their built-in HTTP authentication
dialog for AJAX requests that require authentication.
ArangoDB will still return an HTTP 401 (Unauthorized) if the request doesn't
contain valid credentials, but it will omit the `WWW-Authenticate` header,
allowing clients to bypass the browser's authentication dialog.
* added REST API method HTTP GET `/_api/job/job-id` to query the status of an
async job without potentially fetching it from the list of done jobs
* fixed non-intuitive behavior in jobs API: previously, querying the status
of an async job via the API HTTP PUT `/_api/job/job-id` removed a currently
executing async job from the list of queryable jobs on the server.
Now, when querying the result of an async job that is still executing,
the job is kept in the list of queryable jobs so its result can be fetched
by a subsequent request.
* use a new data structure for the edge index of an edge collection. This
improves the performance for the creation of the edge index and in
particular speeds up removal of edges in graphs. Note however that
this change might change the order in which edges starting at
or ending in a vertex are returned. However, this order was never
guaranteed anyway and it is not sensible to guarantee any particular
order.
* provide a size hint to edge and hash indexes when initially filling them
this will lead to less re-allocations when populating these indexes
this may speed up building indexes when opening an existing collection
* don't requeue identical context methods in V8 threads in case a method is
already registered
* removed arangod command line option `--database.remove-on-compacted`
* export the sort attribute for graph traversals to the HTTP interface
* add support for arangodump/arangorestore for clusters
-- ArangoDB Maintainer <info@arangodb.org> Sat, 10 May 2014 19:37:47 +0200
arangodb (2.1.0a4-1.1) stable; urgency=low
* Changed to Version 2.1.0-alpha4
* added server-side periodic task management functions:
- require("org/arangodb/tasks").register(): registers a periodic task
- require("org/arangodb/tasks").unregister(): unregisters and removes a
periodic task
- require("org/arangodb/tasks").get(): retrieves a specific tasks or all
existing tasks
the previous undocumented function `internal.definePeriodic` is now
deprecated and will be removed in a future release.
* decrease the size of some seldomly used system collections on creation.
This will make these collections use less disk space and mapped memory.
* added AQL date functions
* added AQL FLATTEN() and FLATTEN_RECURSIVE() list functions
* added index memory statistics to `db.<collection>.figures()` function
The `figures` function will now return a sub-document `indexes`, which lists
the number of indexes in the `count` sub-attribute, and the total memory
usage of the indexes in bytes in the `size` sub-attribute.
* added AQL CURRENT_DATABASE() function
This function returns the current database's name.
* added AQL CURRENT_USER() function
This function returns the current user from an AQL query. The current user is the
username that was specified in the `Authorization` HTTP header of the request. If
authentication is turned off or the query was executed outside a request context,
the function will return `null`.
* fixed issue #796: Searching with newline chars broken?
fixed slightly different handling of backslash escape characters in a few
AQL functions. Now handling of escape sequences should be consistent, and
searching for newline characters should work the same everywhere
* added OpenSSL version check for configure
It will report all OpenSSL versions < 1.0.1g as being too old.
`configure` will only complain about an outdated OpenSSL version but not stop.
* require C++ compiler support (requires g++ 4.8, clang++ 3.4 or Visual Studio 13)
* less string copying returning JSONified documents from ArangoDB, e.g. via
HTTP GET `/_api/document/<collection>/<document>`
* issue #798: Lower case http headers from arango
This change allows returning capitalized HTTP headers, e.g.
`Content-Length` instead of `content-length`.
The HTTP spec says that headers are case-insensitive, but
in fact several clients rely on a specific case in response
headers.
This change will capitalize HTTP headers if the `X-Arango-Version`
request header is sent by the client and contains a value of at
least `20100` (for version 2.1). The default value for the
compatibility can also be set at server start, using the
`--server.default-api-compatibility` option.
* simplified usage of `db._createStatement()`
Previously, the function could not be called with a query string parameter as
follows:
db._createStatement(queryString);
Calling it as above resulted in an error because the function expected an
object as its parameter. From now on, it's possible to call the function with
just the query string.
* make ArangoDB not send back a `WWW-Authenticate` header to a client in case the
client sends the `X-Omit-WWW-Authenticate` HTTP header.
This is done to prevent browsers from showing their built-in HTTP authentication
dialog for AJAX requests that require authentication.
ArangoDB will still return an HTTP 401 (Unauthorized) if the request doesn't
contain valid credentials, but it will omit the `WWW-Authenticate` header,
allowing clients to bypass the browser's authentication dialog.
* added REST API method HTTP GET `/_api/job/job-id` to query the status of an
async job without potentially fetching it from the list of done jobs
* fixed non-intuitive behavior in jobs API: previously, querying the status
of an async job via the API HTTP PUT `/_api/job/job-id` removed a currently
executing async job from the list of queryable jobs on the server.
Now, when querying the result of an async job that is still executing,
the job is kept in the list of queryable jobs so its result can be fetched
by a subsequent request.
* use a new data structure for the edge index of an edge collection. This
improves the performance for the creation of the edge index and in
particular speeds up removal of edges in graphs. Note however that
this change might change the order in which edges starting at
or ending in a vertex are returned. However, this order was never
guaranteed anyway and it is not sensible to guarantee any particular
order.
* provide a size hint to edge and hash indexes when initially filling them
this will lead to less re-allocations when populating these indexes
this may speed up building indexes when opening an existing collection
* don't requeue identical context methods in V8 threads in case a method is
already registered
* removed arangod command line option `--database.remove-on-compacted`
* export the sort attribute for graph traversals to the HTTP interface
* add support for arangodump/arangorestore for clusters
-- ArangoDB Maintainer <info@arangodb.org> Sat, 10 May 2014 15:07:44 +0200
arangodb (2.1.0a3-1.1) stable; urgency=low
* Changed to Version 2.1.0-alpha3
* fixed issue #848: db.someEdgeCollection.inEdge does not return correct
-- ArangoDB Maintainer <info@arangodb.org> Sat, 10 May 2014 11:46:54 +0200
arangodb (2.1.0a3-1.1) stable; urgency=low
* Changed to Version 2.1.0-alpha3
* fixed issue #848: db.someEdgeCollection.inEdge does not return correct
-- ArangoDB Maintainer <info@arangodb.org> Sat, 10 May 2014 11:16:50 +0200
arangodb (2.0.nightly-1.1) stable; urgency=low
* Changed to Version 2.0.nightly
-- ArangoDB Maintainer <info@arangodb.org> Tue, 06 May 2014 01:20:47 +0200
arangodb (2.0.7-1.1) stable; urgency=low
* Changed to Version 2.0.7
* issue #839: Foxx Manager missing "unfetch"
* fixed a race condition at startup
this fixes undefined behavior in case the logger was involved directly at
startup, before the logger initialization code was called. This should have
occurred only for code that was executed before the invocation of main(),
e.g. during ctor calls of statically defined objects.
* fixed permission problems under Windows
-- ArangoDB Maintainer <info@arangodb.org> Mon, 05 May 2014 19:23:11 +0200
arangodb (2.0.6-1.1) stable; urgency=low
* Changed to Version 2.0.6
* fixed issue #835: arangosh doesn't show correct database name
-- ArangoDB Maintainer <info@arangodb.org> Tue, 22 Apr 2014 23:19:09 +0200
arangodb (2.0.5-1.1) stable; urgency=low
* Changed to Version 2.0.5
* Fixed a caching problem in IE JS Shell
* added cancelation for async jobs
* upgraded to new gyp for V8
* new Windows installer
-- ArangoDB Maintainer <info@arangodb.org> Mon, 21 Apr 2014 17:02:15 +0200
arangodb (2.0.4-1.1) stable; urgency=low
* Changed to Version 2.0.4
* fixed cluster authentication front-end issues for Firefox and IE, there are
still problems with Chrome
-- ArangoDB Maintainer <info@arangodb.org> Mon, 14 Apr 2014 20:19:04 +0200
arangodb (2.0.3-1.1) stable; urgency=low
* Changed to Version 2.0.3
* fixed AQL optimizer bug
* fixed front-end issues
* added password change dialog
-- ArangoDB Maintainer <info@arangodb.org> Sun, 13 Apr 2014 21:33:43 +0200
arangodb (2.0.2-1.1) stable; urgency=low
* Changed to Version 2.0.2
* during cluster startup, do not log (somewhat expected) connection errors with
log level error, but with log level info
* fixed dashboard modals
* fixed connection check for cluster planning front end: firefox does
not support async:false
* document how to persist a cluster plan in order to relaunch an existing
cluster later
* added REST API method HTTP GET `/_api/job/job-id` to query the status of an
async job without potentially fetching it from the list of done jobs
* fixed non-intuitive behavior in jobs API: previously, querying the status
of an async job via the API HTTP PUT `/_api/job/job-id` removed a currently
executing async job from the list of queryable jobs on the server.
Now, when querying the result of an async job that is still executing,
the job is kept in the list of queryable jobs so its result can be fetched
by a subsequent request.
* improve documentation of db._create and explain the rules and
limitations following from the choice of shardKeys for sharded
collections with more than one shard
-- ArangoDB Maintainer <info@arangodb.org> Sun, 06 Apr 2014 14:38:55 +0200
arangodb (2.0.1-1.1) stable; urgency=low
* Changed to Version 2.0.1
* make ArangoDB not send back a `WWW-Authenticate` header to a client in case the
client sends the `X-Omit-WWW-Authenticate` HTTP header.
This is done to prevent browsers from showing their built-in HTTP authentication
dialog for AJAX requests that require authentication.
ArangoDB will still return an HTTP 401 (Unauthorized) if the request doesn't
contain valid credentials, but it will omit the `WWW-Authenticate` header,
allowing clients to bypass the browser's authentication dialog.
* fixed isses in arango-dfdb:
the dfdb was not able to unload certain system collections, so these couldn't be
inspected with the dfdb sometimes. Additionally, it did not truncate corrupt
markers from datafiles under some circumstances
* added `changePassword` attribute for users
* fixed non-working "save" button in collection edit view of web interface
clicking the save button did nothing. one had to press enter in one of the input
fields to send modified form data
* fixed V8 compile error on MacOS X
* prevent `body length: -9223372036854775808` being logged in development mode for
some Foxx HTTP responses
* fixed several bugs in web interface dashboard
* fixed issue #783: coffee script not working in manifest file
* fixed issue #781: Cant save current query from AQL editor ui
* bumped version in `X-Arango-Version` compatibility header sent by arangosh and other
client tools from `1.5` to `2.0`.
* fixed startup options for arango-dfdb, added details option for arango-dfdb
* fixed display of missing error messages and codes in arangosh
* when creating a collection via the web interface, the collection type was always
"document", regardless of the user's choice
-- ArangoDB Maintainer <info@arangodb.org> Mon, 31 Mar 2014 19:52:56 +0200
arangodb (2.0.1r3-1.1) stable; urgency=low
* Changed to Version 2.0.1-rc3
* make ArangoDB not send back a `WWW-Authenticate` header to a client in case the
client sends the `X-Omit-WWW-Authenticate` HTTP header.
This is done to prevent browsers from showing their built-in HTTP authentication
dialog for AJAX requests that require authentication.
ArangoDB will still return an HTTP 401 (Unauthorized) if the request doesn't
contain valid credentials, but it will omit the `WWW-Authenticate` header,
allowing clients to bypass the browser's authentication dialog.
* fixed isses in arango-dfdb:
the dfdb was not able to unload certain system collections, so these couldn't be
inspected with the dfdb sometimes. Additionally, it did not truncate corrupt
markers from datafiles under some circumstances
* added `changePassword` attribute for users
* fixed non-working "save" button in collection edit view of web interface
clicking the save button did nothing. one had to press enter in one of the input
fields to send modified form data
* fixed V8 compile error on MacOS X
* prevent `body length: -9223372036854775808` being logged in development mode for
some Foxx HTTP responses
* fixed several bugs in web interface dashboard
* fixed issue #783: coffee script not working in manifest file
* fixed issue #781: Cant save current query from AQL editor ui
* bumped version in `X-Arango-Version` compatibility header sent by arangosh and other
client tools from `1.5` to `2.0`.
* fixed startup options for arango-dfdb, added details option for arango-dfdb
* fixed display of missing error messages and codes in arangosh
* when creating a collection via the web interface, the collection type was always
"document", regardless of the user's choice
-- ArangoDB Maintainer <info@arangodb.org> Mon, 31 Mar 2014 10:58:07 +0200
arangodb (2.0.1r2-1.1) stable; urgency=low
* Changed to Version 2.0.1-rc2
* make ArangoDB not send back a `WWW-Authenticate` header to a client in case the
client sends the `X-Omit-WWW-Authenticate` HTTP header.
This is done to prevent browsers from showing their built-in HTTP authentication
dialog for AJAX requests that require authentication.
ArangoDB will still return an HTTP 401 (Unauthorized) if the request doesn't
contain valid credentials, but it will omit the `WWW-Authenticate` header,
allowing clients to bypass the browser's authentication dialog.
* fixed isses in arango-dfdb:
the dfdb was not able to unload certain system collections, so these couldn't be
inspected with the dfdb sometimes. Additionally, it did not truncate corrupt
markers from datafiles under some circumstances
* added `changePassword` attribute for users
* fixed non-working "save" button in collection edit view of web interface
clicking the save button did nothing. one had to press enter in one of the input
fields to send modified form data
* fixed V8 compile error on MacOS X
* prevent `body length: -9223372036854775808` being logged in development mode for
some Foxx HTTP responses
* fixed several bugs in web interface dashboard
* fixed issue #783: coffee script not working in manifest file
* fixed issue #781: Cant save current query from AQL editor ui
* bumped version in `X-Arango-Version` compatibility header sent by arangosh and other
client tools from `1.5` to `2.0`.
* fixed startup options for arango-dfdb, added details option for arango-dfdb
* fixed display of missing error messages and codes in arangosh
* when creating a collection via the web interface, the collection type was always
"document", regardless of the user's choice
-- ArangoDB Maintainer <info@arangodb.org> Fri, 28 Mar 2014 10:30:40 +0100
arangodb (2.0.0-1.1) stable; urgency=low
* Changed to Version 2.0.0
* first 2.0 release
-- ArangoDB Maintainer <info@arangodb.org> Mon, 10 Mar 2014 16:48:11 +0100
arangodb (2.0.0r2-1.1) stable; urgency=low
* Changed to Version 2.0.0-rc2
* fixed cluster authorization
-- ArangoDB Maintainer <info@arangodb.org> Fri, 07 Mar 2014 14:08:21 +0100
arangodb (2.0.0r1-1.1) stable; urgency=low
* Changed to Version 2.0.0-rc1
* added sharding :-)
more detailed documentation on the sharding and cluster features can be found in the user
manual, section **Sharding**
* INCOMPATIBLE CHANGE: using complex values in AQL filter conditions with operators other
than equality (e.g. >=, >, <=, <) will disable usage of skiplist indexes for filter
evaluation.
For example, the following queries will be affected by change:
FOR doc IN docs FILTER doc.value < { foo: "bar" } RETURN doc
FOR doc IN docs FILTER doc.value >= [ 1, 2, 3 ] RETURN doc
The following queries will not be affected by the change:
FOR doc IN docs FILTER doc.value == 1 RETURN doc
FOR doc IN docs FILTER doc.value == "foo" RETURN doc
FOR doc IN docs FILTER doc.value == [ 1, 2, 3 ] RETURN doc
FOR doc IN docs FILTER doc.value == { foo: "bar" } RETURN doc
* INCOMPATIBLE CHANGE: removed undocumented method `collection.saveOrReplace`
this feature was never advertised nor documented nor tested.
* INCOMPATIBLE CHANGE: removed undocumented REST API method `/_api/simple/BY-EXAMPLE-HASH`
this feature was never advertised nor documented nor tested.
* added explicit startup parameter `--server.reuse-address`
This flag can be used to control whether sockets should be acquired with the SO_REUSEADDR
flag.
Regardless of this setting, sockets on Windows are always acquired using the
SO_EXCLUSIVEADDRUSE flag.
* removed undocumented REST API method GET `/_admin/database-name`
* added user validation API at POST `/_api/user/<username>`
* slightly improved users management API in `/_api/user`:
Previously, when creating a new user via HTTP POST, the username needed to be
passed in an attribute `username`. When users were returned via this API,
the usernames were returned in an attribute named `user`. This was slightly
confusing and was changed in 1.5 as follows:
- when adding a user via HTTP POST, the username can be specified in an attribute
`user`. If this attribute is not used, the API will look into the attribute `username`
as before and use that value.
- when users are returned via HTTP GET, the usernames are still returned in an
attribute `user`.
This change should be fully downwards-compatible with the previous version of the API.
* added AQL SLICE function to extract slices from lists
* removed check-server binary
* made module loader more node compatible
* the startup option `--javascript.package-path` for arangosh is now deprecated and does
nothing. Using it will not cause an error, but the option is ignored.
* added coffee script support
* Several UI improvements.
* Exchanged icons in the graphviewer toolbar
* always start networking and HTTP listeners when starting the server (even in
console mode)
* allow vertex and edge filtering with user-defined functions in TRAVERSAL,
TRAVERSAL_TREE and SHORTEST_PATH AQL functions:
// using user-defined AQL functions for edge and vertex filtering
RETURN TRAVERSAL(friends, friendrelations, "friends/john", "outbound", {
followEdges: "myfunctions::checkedge",
filterVertices: "myfunctions::checkvertex"
})
// using the following custom filter functions
-- ArangoDB Maintainer <info@arangodb.org> Sat, 08 Feb 2014 22:27:45 +0100
arangodb (1.4.8-1.1) stable; urgency=low
* Changed to Version 1.4.8
* install foxx apps in the web interface
* fixed a segfault in the import API
-- ArangoDB Maintainer <info@arangodb.org> Sat, 08 Feb 2014 20:41:13 +0100
arangodb (1.4.9-1.1) stable; urgency=low
* Changed to Version 1.4.9
-- ArangoDB Maintainer <info@arangodb.org> Fri, 07 Feb 2014 21:49:50 +0100
arangodb (1.4.8-1.1) stable; urgency=low
* Changed to Version 1.4.8
-- ArangoDB Maintainer <info@arangodb.org> Mon, 27 Jan 2014 13:43:56 +0100
arangodb (1.4.7-1.1) stable; urgency=low
* Changed to Version 1.4.7
-- ArangoDB Maintainer <info@arangodb.org> Thu, 23 Jan 2014 17:21:31 +0100
arangodb (1.4.6-1.1) stable; urgency=low
* Changed to Version 1.4.6
-- ArangoDB Maintainer <info@arangodb.org> Mon, 20 Jan 2014 22:15:44 +0100
arangodb (1.4.5-1.1) stable; urgency=low
* Changed to Version 1.4.5
-- ArangoDB Maintainer <info@arangodb.org> Wed, 15 Jan 2014 17:08:12 +0100
arangodb (1.4.5r2-1.1) stable; urgency=low
* Changed to Version 1.4.5-rc2
-- ArangoDB Maintainer <info@arangodb.org> Mon, 13 Jan 2014 14:46:37 +0100
arangodb (1.4.5r1-1.1) stable; urgency=low
* Changed to Version 1.4.5-rc1
-- ArangoDB Maintainer <info@arangodb.org> Fri, 03 Jan 2014 15:30:12 +0100
arangodb (1.4.4-1.1) stable; urgency=low
* Changed to Version 1.4.4
-- ArangoDB Maintainer <info@arangodb.org> Tue, 24 Dec 2013 10:26:15 +0100
arangodb (1.4.4r1-1.1) stable; urgency=low
* Changed to Version 1.4.4-rc1
-- ArangoDB Maintainer <info@arangodb.org> Sun, 22 Dec 2013 18:43:40 +0100
arangodb (1.4.3-1.1) stable; urgency=low
* Changed to Version 1.4.3
-- ArangoDB Maintainer <info@arangodb.org> Mon, 25 Nov 2013 10:41:14 +0100
arangodb (1.4.3a1-1.1) stable; urgency=low
* Changed to Version 1.4.3-alpha1
-- ArangoDB Maintainer <info@arangodb.org> Fri, 22 Nov 2013 22:11:35 +0100
arangodb (1.4.2-18.4) stable; urgency=low
* Changed to Version 1.4.2
-- ArangoDB Maintainer <info@arangodb.org> Wed, 20 Nov 2013 14:18:14 +0100
arangodb (1.4.2a1-18.4) stable; urgency=low
* Changed to Version 1.4.2-alpha1
-- ArangoDB Maintainer <info@arangodb.org> Sat, 09 Nov 2013 19:23:27 +0100
arangodb (1.4.1-18.4) stable; urgency=low
* Changed to Version 1.4.1
-- ArangoDB Maintainer <info@arangodb.org> Fri, 08 Nov 2013 13:03:44 +0100
arangodb (1.4.1r1-18.4) stable; urgency=low
* Changed to Version 1.4.1-rc1
-- ArangoDB Maintainer <info@arangodb.org> Thu, 07 Nov 2013 22:57:35 +0100
arangodb (1.4.1r1-18.4) stable; urgency=low
* Changed to Version 1.4.1-rc1
-- ArangoDB Maintainer <info@arangodb.org> Thu, 07 Nov 2013 21:20:03 +0100
arangodb (1.4.0-18.1) stable; urgency=low
* Changed to Version 1.4.0
-- ArangoDB Maintainer <info@arangodb.org> Tue, 29 Oct 2013 15:33:15 +0100
arangodb (1.4.0r1-18.1) stable; urgency=low
* Changed to Version 1.4.0-rc1
-- Info <info@triagens.de> Tue, 29 Oct 2013 08:55:47 +0100
arangodb (1.4.0b2-18.1) stable; urgency=low
* Changed to Version 1.4.0-beta2
-- Info <info@triagens.de> Tue, 22 Oct 2013 16:30:46 +0200
arangodb (1.4.0-16) stable; urgency=low
* Changed to Version 1.4.0-alpha1
-- Info <info@triagens.de> Fri, 02 Aug 2013 17:36:00 +0200
arangodb (1.3.2-15) stable; urgency=low
* Changed to Version 1.3.2
-- Info <info@triagens.de> Fri, 21 Jun 2013 13:09:00 +0100
arangodb (1.3.1-14) stable; urgency=low
* Changed to Version 1.3.1
-- Info <info@triagens.de> Fri, 24 May 2013 18:05:00 +0100
arangodb (1.3.0-13) stable; urgency=low
* Changed to Version 1.3.0
-- Info <info@triagens.de> Fri, 10 May 2013 17:12:00 +0100
arangodb (1.2.3-12) stable; urgency=low
* Changed to Version 1.2.3
-- Info <info@triagens.de> Fri, 12 Apr 2013 12:35:00 +0100
arangodb (1.2.2-11) stable; urgency=low
* Changed to Version 1.2.2
-- Info <info@triagens.de> Tue, 26 Mar 2013 14:48:00 +0100
arangodb (1.2.1-10) stable; urgency=low
* Changed to Version 1.2.1
-- Info <info@triagens.de> Fri, 15 Mar 2013 06:28:00 +0100
arangodb (1.2.0-9) stable; urgency=low
* Changed to Version 1.2.0
-- Info <info@triagens.de> Fri, 1 Mar 2013 14:15:00 +0100
arangodb (1.2.beta3-9) stable; urgency=low
* Changed to Version 1.2.beta3
-- Info <info@triagens.de> Fri, 22 Feb 2013 17:22:00 +0100
arangodb (1.2.beta2-6) stable; urgency=low
* Changed to Version 1.2.beta2
-- Info <info@triagens.de> Fri, 15 Feb 2013 14:39:00 +0100
arangodb (1.2.beta1-4) stable; urgency=low
* Changed to Version 1.2.beta1
-- Info <info@triagens.de> Mon, 4 Feb 2013 10:02:00 +0100
arangodb (1.1.2-3) stable; urgency=low
* Changed to Version 1.1.2
-- Info <info@triagens.de> Mon, 21 Jan 2013 08:29:00 +0100
arangodb (1.1.1-2) stable; urgency=low
* Changed to Version 1.1.1
-- Info <info@triagens.de> Tue, 18 Dec 2012 13:50:00 +0100
arangodb (1.1.0-0) stable; urgency=low
* Changed to Version 1.1.0 (final)
-- Info <info@triagens.de> Wed, 5 Dec 2012 15:05:00 +0100
arangodb (1.1.0-0) stable; urgency=low
* Changed to Version 1.1.0 ()beta)
-- Info <info@triagens.de> Tue, 16 Oct 2012 07:37:00 +0200
arangodb (1.0.99-0) stable; urgency=low
* Initial Release
-- Info <info@triagens.de> Wed, 5 Sep 2012 17:50:38 +0200