wrote NewFeatures doc

CHANGELOG

@@ -193,7 +193,7 @@ v2.8.0-alpha1 (2015-12-03)
 
   the index will now contain the individual values `"AQL"`, `"ArangoDB"` and `"Index"`.
   
-  Now the index will be for finding all documents having `"ArangoDB"` somewhere in their
+  Now the index can be used for finding all documents having `"ArangoDB"` somewhere in their
   tags array using the following AQL query:
     
       FOR doc IN colName 

Documentation/Books/Users/NewFeatures/NewFeatures28.mdpp

@@ -0,0 +1,258 @@
+!CHAPTER Features and Improvements
+
+The following list shows in detail which features have been added or improved in
+ArangoDB 2.8. ArangoDB 2.8 also contains several bugfixes that are not listed
+here. For a list of bugfixes, please consult the
+[CHANGELOG](https://github.com/arangodb/arangodb/blob/devel/CHANGELOG).
+
+!SECTION AQL improvements
+
+!SUBSECTION Array Indexes
+
+Hash indexes and skiplist indexes can now optionally be defined for array values 
+so that they index individual array members instead of the entire array value.
+  
+To define an index for array values, the attribute name is extended with the
+expansion operator `[*]` in the index definition.
+
+Example:
+ 
+``` 
+db._create("posts");
+db.posts.ensureHashIndex("tags[*]");
+```
+  
+When given the following document
+
+```json  
+{ 
+  "tags": [ 
+    "AQL", 
+    "ArangoDB", 
+    "Index" 
+  ] 
+}
+```
+
+this index will now contain the individual values `"AQL"`, `"ArangoDB"` and `"Index"`.
+  
+Now the index can be used for finding all documents having `"ArangoDB"` somewhere in 
+their `tags` array using the following AQL query:
+
+```    
+FOR doc IN posts
+  FILTER "ArangoDB" IN doc.tags[*] 
+  RETURN doc
+```
+
+It is also possible to create an index on sub-attributes of array values. This makes 
+sense when the index attribute is an array of objects, e.g.
+
+```js
+db._drop("posts");
+db._create("posts");
+db.posts.ensureIndex({ type: "hash", fields: [ "tags[*].name" ] });
+db.posts.insert({ tags: [ { name: "AQL" }, { name: "ArangoDB" }, { name: "Index" } ] });
+db.posts.insert({ tags: [ { name: "AQL" }, { name: "2.8" } ] });
+```
+
+The following query will then use the array index:
+
+```
+FOR doc IN posts
+  FILTER 'AQL' IN doc.tags[*].name
+  RETURN doc
+```
+
+Array values will automatically be de-duplicated before being inserted into an array index.
+
+Please note that filtering using array indexes only works from within AQL queries and
+only if the query filters on the indexed attribute using the `IN` operator. The other
+comparison operators (`==`, `!=`, `>`, `>=`, `<`, `<=`) currently do not use array
+indexes.
+
+
+!SUBSECTION Optimizer improvements
+
+The AQL query optimizer can now use indexes if multiple filter conditions on attributes of
+the same collection are combined with logical ORs, and if the usage of indexes would completely
+cover these conditions.
+
+For example, the following queries can now use two independent indexes on `value1` and `value2`
+(the latter query requires that the indexes are skiplist indexes due to usage of the `<` and `>`
+comparison operators):
+
+```
+FOR doc IN collection FILTER doc.value1 == 42 || doc.value2 == 23 RETURN doc
+FOR doc IN collection FILTER doc.value1 < 42 || doc.value2 > 23 RETURN doc
+```
+
+
+!SUBSECTION AQL functions added
+
+The following AQL functions have been added in 2.8:
+
+* `POW(base, exponent)`: returns the *base* to the exponent *exp*
+
+* `UNSET_RECURSIVE(document, attributename, ...)`: recursively removes the attributes 
+  *attributename* (can be one or many) from *document* and its sub-documents. All other 
+  attributes will be preserved.
+  Multiple attribute names can be specified by either passing multiple individual string argument 
+  names, or by passing an array of attribute names:
+
+      UNSET_RECURSIVE(doc, '_id', '_key', 'foo', 'bar')
+      UNSET_RECURSIVE(doc, [ '_id', '_key', 'foo', 'bar' ])
+
+* `IS_DATESTRING(value)`: returns true if *value* is a string that can be used in a date function. 
+  This includes partial dates such as *2015* or *2015-10* and strings containing
+  invalid dates such as *2015-02-31*. The function will return false for all 
+  non-string values, even if some of them may be usable in date functions.
+
+
+!SUBSECTION Miscellaneous improvements
+
+* the ArangoShell now provides the convenience function `db._explain(query)` for retrieving 
+  a human-readable explanation of AQL queries. This function is a shorthand for 
+  `require("org/arangodb/aql/explainer").explain(query)`.
+
+* improved performance of skipping over many documents in an AQL query when no
+  indexes and no filters are used, e.g.
+
+      FOR doc IN collection
+        LIMIT 1000000, 10
+        RETURN doc
+
+* added cluster execution site info in execution plan explain output for AQL queries
+
+* for 30+ AQL functions there is now an additional implementation in C++ that removes
+  the need for internal data conversion when the function is called
+
+* the AQL editor in the web interface now supports using bind parameters
+
+
+!SECTION Deadlock detection
+
+ArangoDB 2.8 now has an automatic deadlock detection for transactions.
+
+A deadlock is a situation in which two or more concurrent operations (user transactions
+or AQL queries) try to access the same resources (collections, documents) and need to 
+wait for the others to finish, but none of them can make any progress.
+
+In case of such deadlock, there would be no progress for any of the involved 
+transactions, and none of the involved transactions could ever complete. This is
+completely undesirable, so the new automatic deadlock detection mechanism in ArangoDB
+will automatically kick in and abort one of the transactions involved in such deadlock. 
+Aborting means that all changes done by the transaction will be rolled back and error 
+29 (`deadlock detected`) will be thrown. 
+
+Client code (AQL queries, user transactions) that accesses more than one collection 
+should be aware of the potential of deadlocks and should handle the error 29 
+(`deadlock detected`) properly, either by passing the exception to the caller or 
+retrying the operation.
+
+
+!SECTION Replication
+
+The following improvements for replication have been made in 2.8 (note: most of them
+have been backported to ArangoDB 2.7 as well):
+
+* added `autoResync` configuration parameter for continuous replication. 
+ 
+  When set to `true`, a replication slave will automatically trigger a full data 
+  re-synchronization with the master when the master cannot provide the log data 
+  the slave had asked for. Note that `autoResync` will only work when the option
+  `requireFromPresent` is also set to `true` for the continuous replication, or
+  when the continuous syncer is started and detects that no start tick is present.
+    
+  Automatic re-synchronization may transfer a lot of data from the master to the
+  slave and may be expensive. It is therefore turned off by default. 
+  When turned off, the slave will never perform an automatic re-synchronization
+  with the master.
+
+* added `idleMinWaitTime` and `idleMaxWaitTime` configuration parameters for
+  continuous replication. 
+
+  These parameters can be used to control the minimum and maximum wait time the 
+  slave will (intentionally) idle and not poll for master log changes in case the 
+  master had sent the full logs already. 
+  The `idleMaxWaitTime` value will only be used when `adapativePolling` is set
+  to `true`. When `adaptivePolling` is disable, only `idleMinWaitTime` will be
+  used as a constant time span in which the slave will not poll the master for
+  further changes. The default values are 0.5 seconds for `idleMinWaitTime` and
+  2.5 seconds for `idleMaxWaitTime`, which correspond to the hard-coded values
+  used in previous versions of ArangoDB.
+
+* added `initialSyncMaxWaitTime` configuration parameter for initial and continuous
+  replication
+
+  This option controls the maximum wait time (in seconds) that the initial 
+  synchronization will wait for a response from the master when fetching initial 
+  collection data. If no response is received within this time period, the initial
+  synchronization will give up and fail. This option is also relevant for 
+  continuous replication in case *autoResync* is set to *true*, as then the
+  continuous replication may trigger a full data re-synchronization in case
+  the master cannot the log data the slave had asked for.
+
+* HTTP requests sent from the slave to the master during initial synchronization
+  will now be retried if they fail with connection problems.
+ 
+* the initial synchronization now logs its progress so it can be queried using
+  the regular replication status check APIs.
+
+* added `async` attribute for `sync` and `syncCollection` operations called from
+  the ArangoShell. Setthing this attribute to `true` will make the synchronization 
+  job on the server go into the background, so that the shell does not block. The
+  status of the started asynchronous synchronization job can be queried from the 
+  ArangoShell like this:
+
+      /* starts initial synchronization */
+      var replication = require("org/arangodb/replication");
+      var id = replication.sync({
+        endpoint: "tcp://master.domain.org:8529",
+        username: "myuser",
+        password: "mypasswd",
+        async: true
+      });
+
+      /* now query the id of the returned async job and print the status */
+      print(replication.getSyncResult(id));
+
+  The result of `getSyncResult()` will be `false` while the server-side job
+  has not completed, and different to `false` if it has completed. When it has
+  completed, all job result details will be returned by the call to `getSyncResult()`.
+
+* the web admin interface dashboard now shows a server's replication status
+  at the bottom of the page
+
+
+!SECTION Web Admin Interface
+  
+The following improvements have been made for the web admin interface:
+
+* the AQL editor now has support for bind parameters. The bind parameter values can
+  be edited in the web interface and saved with a query for future use.
+
+* the AQL editor now allows canceling running queries. This can be used to cancel
+  long-running queries without switching to the *query management* section.
+
+* the dashboard now provides information about the server's replication status at
+  the bottom of the page. This can be used to track either the status of a one-time
+  synchronization or the continuous replication.
+
+
+!SECTION Foxx improvements
+
+* the module resolution used by `require` now behaves more like in node.js
+
+* the `org/arangodb/request` module now returns response bodies for error responses
+  by default. The old behavior of not returning bodies for error responses can be
+  re-enabled by explicitly setting the option `returnBodyOnError` to `false`
+
+
+!SECTION Miscellaneous changes
+
+The startup option `--server.hide-product-header` can be used to make the server 
+not send the HTTP response header `"Server: ArangoDB"` in its HTTP responses. This
+can be used to conceal the server make from HTTP clients.
+By default, the option is turned off so the header is still sent as usual.
+

Documentation/Books/Users/SUMMARY.md

@@ -19,7 +19,8 @@
     * [Upgrading to 2.3](Upgrading/Upgrading23.md)
     * [Upgrading to 2.2](Upgrading/Upgrading22.md)
   * [Cluster setup](Installing/Cluster.md)
-* [Whats New](NewFeatures/NewFeatures27.md)
+* [Whats New](NewFeatures/NewFeatures28.md)
+  * [Whats New in 2.7](NewFeatures/NewFeatures27.md)
   * [Whats New in 2.6](NewFeatures/NewFeatures26.md)
   * [Whats New in 2.5](NewFeatures/NewFeatures25.md)
   * [Whats New in 2.4](NewFeatures/NewFeatures24.md)

Documentation/Books/Users/Transactions/LockingAndIsolation.mdpp

@@ -147,7 +147,7 @@ will automatically abort one of the transactions involved in such deadlock. Abor
 means that all changes done by the transaction will be rolled back and error 29 
 (`deadlock detected`) will be thrown. 
 
-Client code (AQL queries, user transactions) that access more than one collection 
+Client code (AQL queries, user transactions) that accesses more than one collection 
 should be aware of the potential of deadlocks and should handle the error 29 
 (`deadlock detected`) properly, either by passing the exception to the caller or 
 retrying the operation.