---
feature_story: FS_06_99_43_60
feature_title: array `prop_value`
feature_status: TEST
---

# Feature

This feature is about "multiple values" (list) vs "single value" per `prop_name` = arrays vs scalars.

Assigning multiple values per `prop_name` is equivalent of placing same `data_envelope`
into multiple coordinates within discrete space.

In other words, `data_envelope` is supposed to be search-able by any of the value from `prop_value` list
for that `prop_name` coordinate.

# Problem

Participation of multiple values per `arg_name` in CLI query is problematic:
*   Do we use logical `OR` or `AND` to match?
*   How many values to interrogate user before switching to the next `arg_name`?

# Solution

But interrogating user for only one of the value (just like interrogating scalar value) is simple.

# Implementation

During loading, `data_envelope` fields which can contain list/array value may contain scalar values
(which is equivalent to having singleton list/array).
In fact, there should be nothing special to do:
*   to load array list/array fields values, simply change value from scalar value `"a"` to list/array `[ "a" ]`.
*   to query array list/array fields values, simply specify scalar value `"c"` (as for querying scalar values).

# Why do we need that complexity?

The other approach is to place multiple copies of original `data_envelope`
to all those coordinate values in discrete space.
Then, when searched, user would need to specify all those coordinates explicitly (to differentiate among copies).
With support of array fields, these copies disappear, and the search would lock on single object
as soon as one of the value within array is specified.

# Why interrogating for one value only?

At this moment, the user is interrogated for one of the values (one enum item from enum set) per `prop_name`.
With this feature, when there are multiple values per `prop_name` per `data_envelope`,
we can interrogate same `prop_name` multiple times, but until when?
The problem similar to FS_18_64_57_18 function varargs (not as `data_evenlope` set, but as `prop_name` value set).

Conceptually, the simplest solution is to simply follow existing approach -
interrogate for single value per `prop_name`.
The fact that we want to find a `data_envelope` by "only one of multiple values"
(compare with "one of single value" for searching scalar values) conveniently does not change "one of" part.
This may be differently handled in other apps, but `argrelay` focuses on sensible minimal syntax -
what simple search queries `argrelay` is for.
Searching "one of" also drops any debate whether logical `OR` or logical `AND` has to be used -
it always logical `IN` (where scalar value is treated as array value with one value).

# MongoDB support

See: https://www.mongodb.com/docs/manual/tutorial/query-arrays/

# See also

Initially implemented as this issue: https://github.com/argrelay/argrelay/issues/19

