1
0
Fork 0

Expand on pre-2.8 differences

[skip ci]
This commit is contained in:
Alan Plum 2016-06-17 16:40:25 +02:00
parent 43574e509e
commit d780d3335c
No known key found for this signature in database
GPG Key ID: 8ED72A9A323B6EFD
2 changed files with 25 additions and 15 deletions

View File

@ -65,16 +65,6 @@ The `@arangodb/foxx` module also provides the same exports as in 2.8, namely:
* `getExports` and `requireApp` from `@arangodb/foxx/manager`
* `queues` from `@arangodb/foxx/queues`
!SECTION Incompatibilities with 2.8 and earlier
Any feature not supported in 2.8 will also not work in legacy compatibility mode. When migrating from an older version of ArangoDB it is a good idea to migrate to ArangoDB 2.8 first for an easier upgrade path.
As built-in support for CoffeeScript was removed in 3.0 any service using CoffeeScript source files directly will not work in legacy compatibility mode. If you want to use an alternative language like CoffeeScript, make sure to pre-compile the raw source files to JavaScript and use the compiled JavaScript files in the service.
The `@arangodb/request` module when used with the `json` option previously overwrote the string in the `body` property of the response object of the response with the parsed JSON body. In 2.8 this was changed so the parsed JSON body is added as the `json` property of the response object in addition to overwriting the `body` property. In 3.0 and later (including legacy compatibility mode) the `body` property is no longer overwritten and must use the `json` property instead. Note that this only affects code using the `json` option when making the request.
The "magical comments" that could be used to supply documentation for controllers in ArangoDB 2.x are no longer supported and need to be replaced with calls to the controller's `description` and `summary` methods.
The utility module `lodash` is now available and should be used instead of `underscore`, but both modules will continue to be provided.
Additionally, any feature not supported in 2.8 will also not work in legacy compatibility mode. When migrating from an older version of ArangoDB it is a good idea to migrate to ArangoDB 2.8 first for an easier upgrade path.
**Note:** The `org/arangodb` module is aliased to the new name `@arangodb` in ArangoDB 3.0.0 and the `@arangodb` module was aliased to the old name `org/arangodb` in ArangoDB 2.8.0. Either one will work in 2.8 and 3.0 but outside of legacy services you should use `@arangodb` going forward.
Additionally please note the differences laid out in the section titled ["Migrating from pre-2.8"](Migrating2x.md#migrating-from-pre-28) in the migration guide.

View File

@ -4,8 +4,6 @@ When migrating services from older versions of ArangoDB it is generally recommen
This chapter outlines the major differences in the Foxx API between ArangoDB 2.8 and ArangoDB 3.0.
Additionally please note the differences laid out in the section titled ["Incompatibilities with 2.8 and earlier"](LegacyMode.md#incompatibilities-with-28-and-earlier) in the chapter covering the legacy compatibility mode.
!SECTION Migrating from pre-2.8
When migrating from a version older than ArangoDB 2.8 please note that starting with ArangoDB 2.8 the behaviour of the `require` function more closely mimics the behaviour observed in Node.js and module bundlers for browsers, e.g.:
@ -38,6 +36,26 @@ In a file `/routes/examples.js` (relative to the root folder of the service):
This behaviour is incompatible with the source code generated by the Foxx generator in the web interface before ArangoDB 2.8.
**Note:** The `org/arangodb` module is aliased to the new name `@arangodb` in ArangoDB 3.0.0 and the `@arangodb` module was aliased to the old name `org/arangodb` in ArangoDB 2.8.0. Either one will work in 2.8 and 3.0 but outside of legacy services you should use `@arangodb` going forward.
!SUBSECTION Foxx queue
In ArangoDB 2.6 Foxx introduced a new way to define queued jobs using Foxx scripts to replace the function-based job type definitions which were causing problems when restarting the server. The function-based jobs have been removed in 2.7 and are no longer supported at all.
!SUBSECTION CoffeeScript
ArangoDB 3.0 no longer provides built-in support for CoffeeScript source files, even in legacy compatibility mode. If you want to use an alternative language like CoffeeScript, make sure to pre-compile the raw source files to JavaScript and use the compiled JavaScript files in the service.
!SUBSECTION The request module
The `@arangodb/request` module when used with the `json` option previously overwrote the string in the `body` property of the response object of the response with the parsed JSON body. In 2.8 this was changed so the parsed JSON body is added as the `json` property of the response object in addition to overwriting the `body` property. In 3.0 and later (including legacy compatibility mode) the `body` property is no longer overwritten and must use the `json` property instead. Note that this only affects code using the `json` option when making the request.
!SUBSECTION Bundled NPM modules
The bundled NPM modules have been upgraded and may include backwards-incompatible changes, especially the API of `joi` has changed several times. If in doubt you should bundle your own versions of these modules to ensure specific versions will be used.
The utility module `lodash` is now available and should be used instead of `underscore`, but both modules will continue to be provided.
!SECTION Manifest
Many of the fields that were required in ArangoDB 2.x are now optional and can be safely omitted.
@ -559,12 +577,14 @@ The names of some attributes of the request object have been adjusted to more cl
* `req.user` is now called `req.arangoUser`
Some attributes have been removed:
Some attributes have been removed or changed:
* `req.cookies` has been removed entirely (use `req.cookie(name)`)
* `req.requestBody` has been removed entirely (see below)
* `req.suffix` is now a string rather than an array
Additionally the `req.server` and `req.client` attributes are no longer available. The information is now exposed in a way that can (optionally) transparently handle proxy forwarding headers:
* `req.hostname` defaults to `req.server.address`