You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: