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
In release 0.3 we remove the code for creating the mapping of the 3 kind of reports in OpenSearch.
The mapping will be created automatically by Opensearch with the 1st report being inserted into OpenSearch.
However, now we find that there will be problems with the auto-generated mapping, here are 2 examples:
Suppose, there is a field which is the date type, this automatic mechanism will take the field as a string field, then we lose the chance to using date to filter the reports.
Suppose, there is a filed which is the long type, this automatic mechanism will take the field as a string filed, then we lose the chance to do max function on the field to find the largest value.
When we remove the create mapping logic from the scanners, we are thinking that the scanner should only communicate with the exporter, and it should not know anything about the consumers. This is still right now.
So the solution for this problem could be add the creating mapping logic back to the exporter. For example, the exporter can help to create the mappings of all the known scanners at init stage. The mapping of each scanner is owned by each author of each scanner.
The text was updated successfully, but these errors were encountered:
In release 0.3 we remove the code for creating the mapping of the 3 kind of reports in OpenSearch.
The mapping will be created automatically by Opensearch with the 1st report being inserted into OpenSearch.
However, now we find that there will be problems with the auto-generated mapping, here are 2 examples:
Suppose, there is a field which is the date type, this automatic mechanism will take the field as a string field, then we lose the chance to using date to filter the reports.
Suppose, there is a filed which is the long type, this automatic mechanism will take the field as a string filed, then we lose the chance to do max function on the field to find the largest value.
When we remove the create mapping logic from the scanners, we are thinking that the scanner should only communicate with the exporter, and it should not know anything about the consumers. This is still right now.
So the solution for this problem could be add the creating mapping logic back to the exporter. For example, the exporter can help to create the mappings of all the known scanners at init stage. The mapping of each scanner is owned by each author of each scanner.
The text was updated successfully, but these errors were encountered: