mxcl/homebrew — pull request #17860 by fceller (2013-02-15 14:47:25+00:00)
Title: Updated to ArangoDB 1.2.beta2 for --devel

v1.2.beta2 (2013-02-15)
-----------------------

* fixed issue #405: 1.2 compile warnings

* fixed issue #333: [debian] Group "arangodb" is not used when starting vie init.d script

* added optional parameter 'excludeSystem' to GET /_api/collection
This parameter can be used to disable returning system collections in the list
of all collections.

* added AQL functions KEEP() and UNSET()

* fixed issue #348: "HTTP Interface for Administration and Monitoring"
documentation errors.

* fix stringification of specific positive int64 values. Stringification of int64
values with the upper 32 bits cleared and the 33rd bit set were broken.

* issue #395: Collection properties() function should return 'isSystem' for
Javascript and REST API

* make server stop after upgrade procedure when invoked with `--upgrade option`.
When started with the `--upgrade` option, the server will perfom
the upgrade, and then exit with a status code indicating the result of the
upgrade (0 = success, 1 = failure). To start the server regularly in either
daemon or console mode, the `--upgrade` option must not be specified.
This change was introduced to allow init.d scripts check the result of
the upgrade procedure, even in case an upgrade was successful.
this was introduced as part of issue #391.

* added AQL function EDGES()

* added more crash-protection when reading corrupted collections at startup

* added documentation for AQL function CONTAINS()

* added AQL function LIKE()

* replaced redundant error return code 1520 (Unable to open collection) with error code
1203 (Collection not found). These error codes have the same meanings, but one of
them was returned from AQL queries only, the other got thrown by other parts of
ArangoDB. Now, error 1203 (Collection not found) is used in AQL too in case a
non-existing collection is used.

v1.2.beta1 (2013-02-01)
-----------------------

* fixed issue #382: [Documentation error] Maschine... should be Machine...

* unified history file locations for arangod, arangosh, and arangoirb.
- The readline history for arangod (emergency console) is now stored in file
$HOME/.arangod. It was stored in $HOME/.arango before.
- The readline history for arangosh is still stored in $HOME/.arangosh.
- The readline history for arangoirb is now stored in $HOME/.arangoirb. It was
stored in $HOME/.arango-mrb before.

* fixed issue #381: _users user should have a unique constraint

* allow negative list indexes in AQL to access elements from the end of a list,
e.g. ```RETURN values[-1]``` will return the last element of the `values` list.

* collection ids, index ids, cursor ids, and document revision ids created and
returned by ArangoDB are now returned as strings with numeric content inside.
This is done to prevent some value overrun/truncation in any part of the
complete client/server workflow.
In ArangoDB 1.1 and before, these values were previously returned as
(potentially very big) integer values. This may cause problems (clipping, overrun,
precision loss) for clients that do not support big integers natively and store
such values in IEEE754 doubles internally. This type loses precision after about
52 bits and is thus not safe to hold an id.
Javascript and 32 bit-PHP are examples for clients that may cause such problems.
Therefore, ids are now returned by ArangoDB as strings, with the string
content being the integer value as before.

Example for documents ("_rev" attribute):
- Document returned by ArangoDB 1.1: { "_rev": 1234, ... }
- Document returned by ArangoDB 1.2: { "_rev": "1234", ... }

Example for collections ("id" attribute / "_id" property):
- Collection returned by ArangoDB 1.1: { "id": 9327643, "name": "test", ... }
- Collection returned by ArangoDB 1.2: { "id": "9327643", "name": "test", ... }

Example for cursors ("id" attribute):
- Collection returned by ArangoDB 1.1: { "id": 11734292, "hasMore": true, ... }
- Collection returned by ArangoDB 1.2: { "id": "11734292", "hasMore": true, ... }

* global variables are not automatically available anymore when starting the
arangod Javascript emergency console (i.e. ```arangod --console```).

Especially, the variables `db`, `edges`, and `internal` are not available
anymore. `db` and `internal` can be made available in 1.2 by
```var db = require("org/arangodb").db;``` and
```var internal = require("internal");```, respectively.
The reason for this change is to get rid of global variables in the server
because this will allow more specific inclusion of functionality.

For convenience, the global variable `db` is still available by default in
arangosh. The global variable `edges`, which since ArangoDB 1.1 was kind of
a redundant wrapper of `db`, has been removed in 1.2 completely.
Please use `db` instead, and if creating an edge collection, use the explicit
```db._createEdgeCollection()``` command.

* issue #374: prevent endless redirects when calling admin interface with
unexpected URLs

* issue #373: TRAVERSAL() `trackPaths` option does not work. Instead `paths` does work

* issue #358: added support for CORS

* honor optional waitForSync property for document removal, replace, update, and
save operations in arangosh. The waitForSync parameter for these operations
was previously honored by the REST API and on the server-side, but not when
the waitForSync parameter was specified for a document operation in arangosh.

* calls to db.collection.figures() and /_api/collection//figures now
additionally return the number of shapes used in the collection in the
extra attribute "shapes.count"

* added AQL TRAVERSAL_TREE() function to return a hierchical result from a traversal

* added AQL TRAVERSAL() function to return the results from a traversal

* added AQL function ATTRIBUTES() to return the attribute names of a document

* removed internal server-side AQL functions from global scope.

Now the AQL internal functions can only be accessed via the exports of the
ahuacatl module, which can be included via ```require("org/arangodb/ahuacatl")```.
It shouldn't be necessary for clients to access this module at all, but
internal code may use this module.

The previously global AQL-related server-side functions were moved to the
internal namespace. This produced the following function name changes on
the server:

old name new name
------------------------------------------------------
AHUACATL_RUN => require("internal").AQL_QUERY
AHUACATL_EXPLAIN => require("internal").AQL_EXPLAIN
AHUACATL_PARSE => require("internal").AQL_PARSE

Again, clients shouldn't have used these functions at all as there is the
ArangoStatement object to execute AQL queries.

* fixed issue #366: Edges index returns strange description

* added AQL function MATCHES() to check a document against a list of examples

* added documentation and tests for db.collection.removeByExample

* added --progress option for arangoimp. This will show the percentage of the input
file that has been processed by arangoimp while the import is still running. It can
be used as a rough indicator of progress for the entire import.

* make the server log documents that cannot be imported via /_api/import into the
logfile using the warning log level. This may help finding illegal documents in big
import runs.

* check on server startup whether the database directory and all collection directories
are writable. if not, the server startup will be aborted. this prevents serious
problems with collections being non-writable and this being detected at some pointer
after the server has been started

* allow the following AQL constructs: FUNC(...)[...], FUNC(...).attribute

* fixed issue #361: Bug in Admin Interface. Header disappears when clicking new collection

* Added in-memory only collections

Added collection creation parameter "isVolatile":
if set to true, the collection is created as an in-memory only collection,
meaning that all document data of that collection will reside in memory only,
and will not be stored permanently to disk.
This means that all collection data will be lost when the collection is unloaded
or the server is shut down.
As this collection type does not have datafile disk overhead for the regular
document operations, it may be faster than normal disk-backed collections. The
actual performance gains strongly depend on the underlying OS, filesystem, and
settings though.
This collection type should be used for caches only and not for any sensible data
that cannot be re-created otherwise.
Some platforms, namely Windows, currently do not support this collection type.
When creating an in-memory collection on such platform, an error message will be
returned by ArangoDB telling the user the platform does not support it.

Note: in-memory collections are an experimental feature. The feature might
change drastically or even be removed altogether in a future version of ArangoDB.

* fixed issue #353: Please include "pretty print" in Emergency Console

* fixed issue #352: "pretty print" console.log
This was achieved by adding the dump() function for the "internal" object

* reduced insertion time for edges index
Inserting into the edges index now avoids costly comparisons in case of a hash
collision, reducing the prefilling/loading timer for bigger edge collections

* added fulltext queries to AQL via FULLTEXT() function. This allows search
fulltext indexes from an AQL query to find matching documents

* added fulltext index type. This index type allows indexing words and prefixes of
words from a specific document attribute. The index can be queries using a
SimpleQueryFull object, the HTTP REST API at /_api/simple/fulltext, or via AQL

* added collection.revision() method to determine whether a collection has changed.
The revision method returns a revision string that can be used by client programs
for equality/inequality comparisons. The value returned by the revision method
should be treated by clients as an opaque string and clients should not try to
figure out the sense of the revision id. This is still useful enough to check
whether data in a collection has changed.

* issue #346: adaptively determine NUMBER_HEADERS_PER_BLOCK

* issue #338: arangosh cursor positioning problems

* issue #326: use limit optimisation with filters

* issue #325: use index to avoid sorting

* issue #324: add limit optimisation to AQL

* removed arango-password script and added Javascript functionality to add/delete
users instead. The functionality is contained in module `users` and can be invoked
as follows from arangosh and arangod:
* require("users").save("name", "passwd");
* require("users").replace("name", "newPasswd");
* require("users").remove("name");
* require("users").reload();
These functions are intentionally not offered via the web interface.
This also addresses issue #313

* changed print output in arangosh and the web interface for JSON objects.
Previously, printing a JSON object in arangosh resulted in the attribute values
being printed as proper JSON, but attribute names were printed unquoted and
unescaped. This was fine for the purpose of arangosh, but lead to invalid
JSON being produced. Now, arangosh will produce valid JSON that can be used
to send it back to ArangoDB or use it with arangoimp etc.

* fixed issue #300: allow importing documents via the REST /_api/import API
from a JSON list, too.
So far, the API only supported importing from a format that had one JSON object
on each line. This is sometimes inconvenient, e.g. when the result of an AQL
query or any other list is to be imported. This list is a JSON list and does not
necessary have a document per line if pretty-printed.
arangoimp now supports the JSON list format, too. However, the format requires
arangoimp and the server to read the entire dataset at once. If the dataset is
too big (bigger than --max-upload-size) then the import will be rejected. Even if
increased, the entire list must fit in memory on both the client and the server,
and this may be more resource-intensive than importing individual lines in chunks.

* removed unused parameter --reuse-ids for arangoimp. This parameter did not have
any effect in 1.2, was never publicly announced and did evil (TM) things.

* fixed issue #297 (partly): added whitespace between command line and
command result in arangosh, added shell colors for better usability

* fixed issue #296: system collections not usable from AQL

* fixed issue #295: deadlock on shutdown

* fixed issue #293: AQL queries should exploit edges index

* fixed issue #292: use index when filtering on _key in AQL

* allow user-definable document keys
users can now define their own document keys by using the _key attribute
when creating new documents or edges. Once specified, the value of _key is
immutable.
The restrictions for user-defined key values are:
* the key must be at most 254 bytes long
* it must consist of the letters a-z (lower or upper case), the digits 0-9,
the underscore (_) or dash (-) characters only
* any other characters, especially multi-byte sequences, whitespace or
punctuation characters cannot be used inside key values

Specifiying a document key is optional when creating new documents. If no
document key is specified, ArangoDB will create a document key itself.
There are no guarantees about the format and pattern of auto-generated document
keys other than the above restrictions.
Clients should therefore treat auto-generated document keys as opaque values.
Keys can be used to look up and reference documents, e.g.:
* saving a document: `db.users.save({ "_key": "fred", ... })`
* looking up a document: `db.users.document("fred")`
* referencing other documents: `edges.relations.save("users/fred", "users/john", ...)`

This change is downwards-compatible to ArangoDB 1.1 because in ArangoDB 1.1
users were not able to define their own keys. If the user does not supply a _key
attribute when creating a document, ArangoDB 1.2 will still generate a key of
its own as ArangoDB 1.1 did. However, all documents returned by ArangoDB 1.2 will
include a _key attribute and clients should be able to handle that (e.g. by
ignoring it if not needed). Documents returned will still include the _id attribute
as in ArangoDB 1.1.

* require collection names everywhere where a collection id was allowed in
ArangoDB 1.1 & 1.0
This change requires clients to use a collection name in place of a collection id
at all places the client deals with collections.
Examples:
* creating edges: the _from and _to attributes must now contain collection names instead
of collection ids: `edges.relations.save("test/my-key1", "test/my-key2", ...)`
* retrieving edges: the returned _from and _to attributes now will contain collection
names instead of ids, too: _from: `test/fred` instead of `1234/3455`
* looking up documents: db.users.document("fred") or db._document("users/fred")

Collection names must be used in REST API calls instead of collection ids, too.
This change is thus not completely downwards-compatible to ArangoDB 1.1. ArangoDB 1.1
required users to use collection ids in many places instead of collection names.
This was unintuitive and caused overhead in cases when just the collection name was
known on client-side but not its id. This overhead can now be avoided so clients can
work with the collection names directly. There is no need to work with collection ids
on the client side anymore.
This change will likely require adjustments to API calls issued by clients, and also
requires a change in how clients handle the _id value of returned documents. Previously,
the _id value of returned documents contained the collection id, a slash separator and
the document number. Since 1.2, _id will contain the collection name, a slash separator
and the document key. The same applies to the _from and _to attribute values of edges
that are returned by ArangoDB.

Also removed (now unnecessary) location header in responses of the collections REST API.
The location header was previously returned because it was necessary for clients.
When clients created a collection, they specified the collection name. The collection
id was generated on the server, but the client needed to use the server-generated
collection id for further API calls, e.g. when creating edges etc. Therefore, the
full collection URL, also containing the collection id, was returned by the server in
responses to the collection API, in the HTTP location header.
Returning the location header has become unnecessary in ArangoDB 1.2 because users
can access collections by name and do not need to care about collection ids.