---
feature_story: FS_45_08_22_15
feature_title: data model manipulation
feature_status: PARTIAL
---

TODO: Move details about metadata from FS_74_69_61_79 get set data envelope here.

TODO: TODO_08_25_32_95: redesign `class_to_collection_map`:
      This FS_45_08_22_15 data model manipulation API should replace `class_to_collection_map`.

# Intro

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

# Validation

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

# `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`?

| category   | `class_name`                  | `collection_name`                |
|------------|-------------------------------|----------------------------------|
| defines    | schema for `envelope_payload` | `data_model` with `index_prop`-s |
| 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 within same `collection_name` and search with the same `index_prop`-s
different `class_name`-s (with different `envelope_payload` schema).

# See also

*   FS_56_43_05_79: Search different collections.
*   TODO_00_79_72_55: Remove `static_data` from `server_config`.

