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/<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.