mirror of https://gitee.com/bigwinds/arangodb
Documentation improvments
This commit is contained in:
parent
3f412debf0
commit
8e15e928b0
|
@ -69,7 +69,9 @@ result is defined as follows:
|
|||
- null: *null* is equal to *null*
|
||||
- boolean: *false* is less than *true*
|
||||
- number: numeric values are ordered by their cardinal value
|
||||
- string: string values are ordered using a localized comparison,
|
||||
- string: string values are ordered using a localized comparison, using the configured
|
||||
[server language](../../Manual/Administration/Configuration/index.html#default-language)
|
||||
for sorting according to the alphabetical order rules of that language
|
||||
|
||||
Note: unlike in SQL, *null* can be compared to any value, including *null*
|
||||
itself, without the result being converted into *null* automatically.
|
||||
|
|
|
@ -21,6 +21,8 @@ and the different data models ArangoDB offers.
|
|||
In its purpose, AQL is similar to the Structured Query Language (SQL). AQL supports
|
||||
reading and modifying collection data, but it doesn't support data-definition
|
||||
operations such as creating and dropping databases, collections and indexes.
|
||||
It is a pure data manipulation language (DML), not a data definition language
|
||||
(DDL) or a data control language (DCL).
|
||||
|
||||
The syntax of AQL queries is different to SQL, even if some keywords overlap.
|
||||
Nevertheless, AQL should be easy to understand for anyone with an SQL background.
|
||||
|
|
|
@ -63,11 +63,11 @@ So this question boils down to 'Can I afford the additional effort or do I need
|
|||
|
||||
If you want to only traverse edges of a specific type, there are two ways to achieve this. The first would be
|
||||
an attribute in the edge document - i.e. `type`, where you specify a differentiator for the edge -
|
||||
i.e. `"friends"`, `"family"`, `"maried"` or `"workmates"`, so you can later `FILTER e.type = "friends"`
|
||||
i.e. `"friends"`, `"family"`, `"married"` or `"workmates"`, so you can later `FILTER e.type = "friends"`
|
||||
if you only want to follow the friend edges.
|
||||
|
||||
Another way, which may be more efficient in some cases, is to use different edge collections for different
|
||||
types of edges, so you have `friend_eges`, `family_edges`, `maried_edges` and `workmate_edges` as collection names.
|
||||
types of edges, so you have `friend_eges`, `family_edges`, `married_edges` and `workmate_edges` as collection names.
|
||||
You can then configure several named graphs including a subset of the available edge and vertex collections -
|
||||
or you use anonymous graph queries, where you specify a list of edge collections to take into account in that query.
|
||||
To only follow friend edges, you would specify `friend_edges` as sole edge collection.
|
||||
|
|
|
@ -110,3 +110,12 @@ the index attributes or have non-numeric values in the index attributes
|
|||
will not be indexed. *ensureGeoConstraint* is deprecated and *ensureGeoIndex*
|
||||
should be used instead.
|
||||
|
||||
The index does not provide a `unique` option because of its limited usability.
|
||||
It would prevent identical coordinates from being inserted only, but even a
|
||||
slightly different location (like 1 inch or 1 cm off) would be unique again and
|
||||
not considered a duplicate, although it probably should. The desired threshold
|
||||
for detecting duplicates may vary for every project (including how to calculate
|
||||
the distance even) and needs to be implemented on the application layer as needed.
|
||||
You can write a [Foxx service](../Foxx/index.html) for this purpose and make use
|
||||
of the AQL [geo functions](../../AQL/Functions/Geo.html) to find nearby
|
||||
coordinates supported by a geo index.
|
||||
|
|
|
@ -44,18 +44,18 @@ The primary index of a collection cannot be dropped or changed, and there is no
|
|||
mechanism to create user-defined primary indexes.
|
||||
|
||||
|
||||
!SUBSECTION Edges Index
|
||||
!SUBSECTION Edge Index
|
||||
|
||||
Every [edge collection](../Appendix/Glossary.md#edge-collection) also has an
|
||||
automatically created *edges index*. The edges index provides quick access to
|
||||
automatically created *edge index*. The edge index provides quick access to
|
||||
documents by either their `_from` or `_to` attributes. It can therefore be
|
||||
used to quickly find connections between vertex documents and is invoked when
|
||||
the connecting edges of a vertex are queried.
|
||||
the connecting edges of a vertex are queried.
|
||||
|
||||
Edges indexes are used from within AQL when performing equality lookups on `_from`
|
||||
Edge indexes are used from within AQL when performing equality lookups on `_from`
|
||||
or `_to` values in an edge collections. There are also dedicated functions to
|
||||
find edges given their `_from` or `_to` values that will always make use of the
|
||||
edges index:
|
||||
edge index:
|
||||
|
||||
```js
|
||||
db.collection.edges("<from-value>");
|
||||
|
@ -66,13 +66,14 @@ db.collection.inEdges("<from-value>");
|
|||
db.collection.inEdges("<to-value>");
|
||||
```
|
||||
|
||||
Internally, the edges index is implemented as a hash index. It can be used for equality
|
||||
lookups, but not for range queries or for sorting. As edges indexes are automatically
|
||||
created for edge collections, it is not possible to create user-defined edges indexes.
|
||||
Internally, the edge index is implemented as a hash index, which stores the union
|
||||
of all `_from` and `_to` attributes. It can be used for equality
|
||||
lookups, but not for range queries or for sorting. Edge indexes are automatically
|
||||
created for edge collections. It is not possible to create user-defined edge indexes.
|
||||
However, it is possible to freely use the `_from` and `_to` attributes in user-defined
|
||||
indexes.
|
||||
|
||||
An edges index cannot be dropped or changed.
|
||||
An edge index cannot be dropped or changed.
|
||||
|
||||
|
||||
!SUBSECTION Hash Index
|
||||
|
@ -354,7 +355,7 @@ FOR doc IN posts
|
|||
RETURN doc
|
||||
```
|
||||
|
||||
The following FILTER conditions will not use the array index:
|
||||
The following FILTER conditions will **not use** the array index:
|
||||
|
||||
```js
|
||||
FILTER doc.tags ANY == 'foobar'
|
||||
|
@ -365,7 +366,7 @@ FILTER 'foobar' == doc.tags
|
|||
```
|
||||
|
||||
It is also possible to create an index on subattributes of array values. This makes sense
|
||||
when the index attribute is an array of objects, e.g.
|
||||
if the index attribute is an array of objects, e.g.
|
||||
|
||||
```js
|
||||
db.posts.ensureIndex({ type: "hash", fields: [ "tags[*].name" ] });
|
||||
|
|
|
@ -154,3 +154,15 @@ and
|
|||
```
|
||||
will match.
|
||||
|
||||
!SECTION Persistent Indexes and Server Language
|
||||
|
||||
The order of index entries in persistent indexes adheres to the configured
|
||||
[server language](../Administration/Configuration/README.md#default-language).
|
||||
If, however, the server is restarted with a different language setting as when
|
||||
the persistent index was created, not all documents may be returned anymore and
|
||||
the sort order of those which are returned can be wrong (whenever the persistent
|
||||
index is consulted).
|
||||
|
||||
To fix persistent indexes after a language change, delete and re-create them.
|
||||
Skiplist indexes are not affected, because they are not persisted and
|
||||
automatically rebuilt on every server start.
|
||||
|
|
|
@ -1 +1,26 @@
|
|||
!CHAPTER Release Notes
|
||||
|
||||
!SECTION Whats New
|
||||
|
||||
- [Whats New in 3.0](NewFeatures30.md)
|
||||
- [Whats New in 2.8](NewFeatures28.md)
|
||||
- [Whats New in 2.7](NewFeatures27.md)
|
||||
- [Whats New in 2.6](NewFeatures26.md)
|
||||
- [Whats New in 2.5](NewFeatures25.md)
|
||||
- [Whats New in 2.4](NewFeatures24.md)
|
||||
- [Whats New in 2.3](NewFeatures23.md)
|
||||
- [Whats New in 2.2](NewFeatures22.md)
|
||||
- [Whats New in 2.1](NewFeatures21.md)
|
||||
|
||||
!SECTION Incompatible changes
|
||||
|
||||
Also see [Upgrading](../Administration/Upgrading/README.md) in the
|
||||
Administration chapter.
|
||||
|
||||
- [Incompatible changes in 3.0](UpgradingChanges30.md)
|
||||
- [Incompatible changes in 2.8](UpgradingChanges28.md)
|
||||
- [Incompatible changes in 2.7](UpgradingChanges27.md)
|
||||
- [Incompatible changes in 2.6](UpgradingChanges26.md)
|
||||
- [Incompatible changes in 2.5](UpgradingChanges25.md)
|
||||
- [Incompatible changes in 2.4](UpgradingChanges24.md)
|
||||
- [Incompatible changes in 2.3](UpgradingChanges23.md)
|
||||
|
|
|
@ -92,6 +92,9 @@ it will automatically figure out where the data is stored (read) or to
|
|||
be stored (write). The information about the shards is shared across the
|
||||
coordinators using the Agency.
|
||||
|
||||
Also see [Sharding](../Administration/Sharding/README.md) in the
|
||||
Administration chapter.
|
||||
|
||||
!SUBSECTION Many sensible configurations
|
||||
|
||||
This architecture is very flexible and thus allows many configurations,
|
||||
|
|
Loading…
Reference in New Issue