---
feature_story: FS_45_08_22_15
feature_title: `index_model`
feature_status: PARTIAL
---

# Intro

This feature describes a index model API (AKA metadata to define data).

# DML vs DDL

*   If FS_74_69_61_79 get set `data_envelope` is about DML (Data Manipulation Language),
*   then FS_45_08_22_15 index model is about DDL (Data Definition Language).

But none of it is a "language", it is rather an API (as there is no syntax, but a payload schema).

# Declared `index_model`

All `data_envelope`-s could be scanned to infer `index_model` for get or set operations.

However, the approach is to declare `index_model` so that `data_envelope`-s could be validated against it.

# Condition

REST API (and `index_model`) would be trivial, if it was not needed to be convenient for CLI.
But it does have to be convenient for CLI, so API has to be well thought.

How the convenience requirement is resolved is explained in the next sections.

# CLI-friendly `index_model`

A special metadata `data_envelope` will have to provide (describe) other `data_envelope`-s loaded so far.

Its payload will have to be `index_prop`-s for that `collection_name` to
dynamically create `search_control` structure.

Why do we need `search_control`?
We need it because we want to look up and browse data the same way as for other commands - via command line.

# Validation

Before any `data_envelope` is loaded or any `search_control` is defined,
the `index_model` (e.g. `index_prop`-s) has to be defined as both `data_envelope` and `search_control`
will be validated against that.

Currently, it is defined by loader plugins (which load `data_envelope`-s with that `index_model`).
TODO: TODO_23_17_31_04: publish `index_model` by delegator plugins.

# `class_name` vs `collection_name`

If `collection_name` is often (and can likely be always) matches `class_name` of all `data_envelope`-s,
why do we need to have `class_name`?

TODO: TODO_61_99_68_90: figure out what to do with explicit `envelope_class` `search_prop`

| category   | `class_name`                  | `collection_name`                                     |
|------------|-------------------------------|-------------------------------------------------------|
| defines    | schema for `envelope_payload` | `index_model` with `index_prop`-s for `data_envelope` |
| concept of | `argrelay` framework          | `mongodb` data backend                                |

It just happens that when we want to search within `collection_name`, we normally expect the same `class_name`.

But it is possible to store different `class_name`-s within same `collection_name`,
and search different `class_name`-s with the same `index_prop`-s (with different `envelope_payload` schema).

# See also

*   FS_56_43_05_79: Search different collections.
*   FS_37_57_36_29: containers, envelopes, payloads.
