Arangodb: Documentation: Fulltext index suggests multiple fields

[LaravelFreelancerNL]

My Environment

• __ArangoDB Version__: 3.3
• __Used Package__: ArangoDB PHP ODM

Component, Query & Data

__Affected feature__:
Fulltext index (documentation)

__Problem__:
The 'documentation' is inconsistent on whether a fulltext index can be created one or multiple attributes. By documentation I mean it in the broadest sense. The official docs and any place where information is provided about the fulltext index.

Below I've provided the three places where I noticed inconsistancies.

__Expected result__:
KISS: A consistent and factual description of the current state: 'what is'. Not 'what should be', 'what it will be' or 'what we want it to be'.

WebUI:

Steps to reproduce

1) Create or go to a collection
2) Create a new fulltext index

__Problem__:

The WebUI fulltext label is 'Fields' (the help info is correct, but that is, ofcourse, hidden and requires an additional step before the information is available)

__Expected result__:
The label should just say 'Field' which makes it immediately obvious what is expected.

PHP ODM:

Steps to reproduce

1) open collectionHandler.php
2) Go to createFulltextIndex()

__Problem__:

'...
* @param array $fields - an array of fields
...
public function createFulltextIndex($collectionId, array $fields, $minLength = null)
...etc...'

__Expected result__:
The second parameter should be 'string $field' etc

ArangoDB Documentation

Steps to reproduce

1) Go here: https://docs.arangodb.com/3.3/HTTP/Indexes/Fulltext.html

__Problem__:

'...
fields (string): an array of attribute names. Currently, the array is limited to exactly one attribute
....'

__Expected result__:
'...
field (string): the attribute name.
...'

[graetzer]

the attribute named fields is the standard for all index types in arangodb, we are very unlikely to change that (sorry).
Perhaps you could submit a PR for the PHP driver documentation, if it bothers you ?

[Simran-B]

The properties you can set on index creation in general are:

• type: hash, skiplist, fulltext, persistent, geo{1|2}
• fields: array of attribute names/paths to create the index over
• sparse: whether documents without the attribute or a _null_ value should be indexed
• unique: whether duplicate values are allowed
• deduplicate: if unique is true and this is an array index, then it controls if duplicate values within one array should be ignored or raise a unique constraint violation

Additional properties specific to one index type:

• minLength: minimum word length to index
• geoJson: whether GeoJSON order for latitude and longitude is used (up to 3.3) / if a GeoJSON object is stored (from 3.4.0 on)

The information might be a bit scattered, but it is documented that some of the properties have no meaning for certain index types and what values you should provide.

• Hash, skiplist and persistent indexes support all properties from the first list
• Geo and fulltext indexes are always sparse and never unique
• Fulltext indexes support the minLength property
• Geo indexes support one or two fields. You can store coordinates in an attribute as array like [lat,lng] _(geoJson: false)_ or [lng,lat] _(geoJson: true)_ or as separate attributes lat and lng.
• Fulltext indexes support a single field only:

A fulltext index can be defined on one attribute only, [...]

As @graetzer wrote, all indexes have a fields property and an array of strings is expected. Even if you want to index a single field only, it still has to be a string in an array. In case of fulltext indexes, there is a hard limit of one field. If you try to pass more than a single attribute path, an exception is raised:

ArangoError 10: bad parameter

The geo1 index expects one, geo2 two attribute paths. Otherwise they raise the same exception.

A general overhaul of the indexing chapter is on the to-do list, but not for this year.

[LaravelFreelancerNL]

Thanks for the replies. And no it wasn't a bother, just an inconsistancy I noticed and thought to let you know.