Currently the elements data is stored on the root level of Elasticsearch documents, which leads to possible property name conflicts, which in turn were solved by giving system properties priority.
However this has still two disadvantages:
If new system properties are introduced, it might delete data from Elasticsearch or make such original properties no longer accessible by Elasticsearch.
If overwriting such properties is not handled correctly, then user data might be interpreted as system data, which could lead to security vulnerabilities.
Therefore I propose the following concept:
System properties are stored in the root level of documents instead.
The element's data is stored within the system property data.
This would eliminate the aforementioned points completely, leave a whole namespace for future expansion, and make it more clearer to end users which properties are user defined and which are not.
Currently the elements data is stored on the root level of Elasticsearch documents, which leads to possible property name conflicts, which in turn were solved by giving system properties priority.
However this has still two disadvantages:
Therefore I propose the following concept:
data.This would eliminate the aforementioned points completely, leave a whole namespace for future expansion, and make it more clearer to end users which properties are user defined and which are not.