mirror of https://gitee.com/bigwinds/arangodb
99 lines
6.0 KiB
Plaintext
99 lines
6.0 KiB
Plaintext
!CHAPTER Incompatible changes in ArangoDB 2.5
|
|
|
|
It is recommended to check the following list of incompatible changes **before**
|
|
upgrading to ArangoDB 2.5, and adjust any client programs if necessary.
|
|
|
|
|
|
!SECTION Changed behavior
|
|
|
|
!SUBSECTION Sparse indexes
|
|
|
|
Hash indexes and skiplist indexes can now be created in a sparse variant.
|
|
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. The unique hash index will be created in a non-sparse variant in ArangoDB 2.5.
|
|
|
|
In 2.4 and before, unique hash indexes were implicitly sparse, always excluding `null` values
|
|
from the index. 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 just unique hash
|
|
indexes was considered an inconsistency, and therefore the behavior was cleaned up in 2.5.
|
|
|
|
As of 2.5, hash and skiplist indexes will only be created sparse if sparsity is explicitly requested.
|
|
This may require a change in index-creating client code, but only if the client code creates
|
|
unique hash indexes and if they are still intended to be sparse. In this case, the client code
|
|
should explicitly set the `sparse` flag to `true` when creating a unique hash index.
|
|
|
|
Existing unique hash indexes from 2.4 or before will automatically be migrated so they are still
|
|
sparse after the upgrade to 2.5. For these indexes, the `sparse` attribute will be populated
|
|
automatically with a value of `true`.
|
|
|
|
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. Client index creation code
|
|
therefore does not need to set the `ignoreNull` or `constraint` attributes when creating a geo
|
|
index.
|
|
|
|
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.
|
|
|
|
|
|
!SUBSECTION Moved Foxx applications to a different folder.
|
|
|
|
Until 2.4 foxx apps were stored in the following folder structure:
|
|
`<app-path>/databases/<dbname>/<appname>:<appversion>`.
|
|
This caused some trouble as apps where cached based on name and version and updates did not apply.
|
|
Also 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 the appended APP):
|
|
`<app-path>/_db/<dbname>/<mointpoint>/APP`
|
|
|
|
!SUBSECTION 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.
|
|
|
|
!SUBSECTION 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
|
|
!SECTION Deprecated features
|
|
|
|
* Foxx: method `Model#toJSONSchema(id)` is deprecated, it will raise a warning if you use it. Please use `Foxx.toJSONSchema(id, model)` instead.
|
|
|
|
!SECTION Removed features
|
|
|
|
* Startup switch `--javascript.frontend-development-mode`: Its major purpose was internal development
|
|
anyway. Now the web frontend can be set to development mode similar to any other foxx app.
|
|
* Startup switch `--javascript.dev-app-path`: Was used for the development mode of Foxx. This is
|
|
integrated with the normal app-path now and can be triggered on app level. The second app-path is
|
|
superfluous.
|
|
* Foxx: `controller.collection`: Please use `appContext.collection` instead.
|
|
* Foxx: `FoxxRepository.modelPrototype`: Please use `FoxxRepository.model` instead.
|
|
* Foxx: `Model.extend({}, {attributes: {}})`: Please use `Model.extend({schema: {}})` instead.
|
|
* Foxx: `requestContext.bodyParam(paramName, description, Model)`: Please use `requestContext.bodyParam(paramName, options)` instead.
|
|
* Foxx: `requestContext.queryParam({type: string})`: Please use `requestContext.queryParam({type: joi})` instead.
|
|
* Foxx: `requestContext.pathParam({type: string})`: Please use `requestContext.pathParam({type: joi})` instead.
|
|
* Graph: The modules `org/arangodb/graph` and `org/arangodb/graph-blueprint`: Please use module `org/arangodb/general-graph` instead. NOTE: This does not mean we do not support blueprints any more. General graph covers everything the graph--blueprint did, plus many more features.
|
|
* General-Graph: In the module `org/arangodb/general-graph` the functions `_undirectedRelation` and `_directedRelation` are no longer available. Both functions have been unified to `_relation`.
|
|
|