Document types
Contents
Introduction
In explorer data is organized into Collections.
Each collection may contain a number of documents.
Each document may contain a number of fields.
Each document, must have a document-type: to configure how fields are validated and indexed for later searching.
| There is no limitation that all documents within a collection must have the same document-type. |
| In a search result, a search result item is typically a representation of some fields from a single document. |
Document-types table
The table will show a list of the document-types.
Each row represents a document-type and will have a button to edit the document-type.
By default a row will show:
How many documents, in total, uses the document-type.
How many (enabled) fields the document-type has.
A comma separated list of the (enabled) fields it has.
If you toggle 'Show all fields', each row will also show:
How many documents, per collection, uses the document-type.
Whether addField is true or false.
A button to open a dialog to confirm deletion of a document-type.
New/Edit
Settings tab
Name
Each document-type needs to have an unique name.
| In order to keep API’s consistent the name is limitied to the regexp /^[a-z][a-z0-9_]*$/. |
| If you try to input a name which is already in use, you will get a form validation error and will be unable to create the document-type. |
| The name cannot be changed after a document-type is created. You can delete a document-type, but that will break any API’s that uses the document-type. |
Add fields
There are multiple ways of persisting data to Explorer. For instance the Document REST API and Collectors, which both uses the Document Layer.
When addFields is true, and the Document layer encounters a field, which is not defined in the document-type, it will automatically detect Value type for a field and add it to the document-type.
Fields tab
Fields table
The table will show a list of the fields, and their settings, which are defined in the document-type.
Each row represents a field and will have a button to edit the field.
If a row is striked-through, it means that field is currently disabled.
Below the table there is a button to add new fields.
Add/Edit field
Name
Each field needs to have a name, which is unique within the document-type.
| In order to keep API’s consistent the name is limitied to the regexp /^[a-z][a-z0-9_.]*$/. |
| Fields can be nested, a dot '.' is used to indicate nesting. For instance you can have a field called: 'person', which should have the value-type 'set'. The you can have a nested field called: 'person.name', with the value-type 'string'. |
| If you try to input a name which is already in use, you will get a form validation error and will be unable to add the field. |
| The name cannot be changed after a field is added. You can delete a field, but that will break any API’s that uses the field. It’s safer to disable a field. |
Min
Setting min to 0 means the field is optional. Setting it to anything larger than 0 means it’s a required field.
| This option is only enforced when validateOccurrences=true, it’s disabled by default. |
Max
Setting max to 0 means there is no limit on how many values the field can have.
| This option is only enforced when validateOccurrences=true, it’s disabled by default. |
Indexing
See Config Options.
Fulltext
See Config Options.
Ngram
See Config Options.
Path
See Config Options.
Active
In the Interface GraphQL API, one may use a field name inside Inline fragments.
| If you delete a field that is in use that way, the GraphQL query will no longer validate and throw an error rather than returning the field without a value. |
| Instead of deleting a field, you can disable it. Then the field should simply return null, rather than causing a GraphQL query schema validation error. |