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

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).

# 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 data model manipulation is about DDL (Data Definition Language).

But none of it is "Language", it is rather an API (as there is no syntax).

# Declared `data_model`

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

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

# Condition

REST API (and `data_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 explained in the next sections.

# CLI-friendly `data_model`

TODO: TODO_98_35_14_72: exclude `class_name` from `search_control`:
      There should not be `envelope_class` inside that metadata `data_envelope`.

A special metadata `data_envelope` will have to provide (describe) other `data_envelope`-s loaded so far:
*   `collection_name`
*   `envelope_class`
Its payload will have to be `index_props` of that `collection_name`.

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

TODO: TODO_98_35_14_72: exclude `class_name` from `search_control`

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.
