-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] The non-humanly-readable fields may have never existed in the OpenSearch fork. #423
Comments
Did some research and found out, that there is a
|
If I understand the java code correctly than the human fields should be of type string all the time. What I don't understand is what is happening with the rawValue as I don't understand the java code. |
@dblock I am looking though the spec and the Therefore I suggest following options:
Depending if we prefer reverencing a schema that is of a single type or directly using the type. I am not 100% sure what the expected benefit of referencing a schema of a single type is. I could only thing of having one place to change the type for all but I am not sure this will ever happen? |
I personally prefer a type like I'd defer to @nhtruong of what we should do, and I think we should update https://github.com/opensearch-project/opensearch-api-specification/blob/main/DEVELOPER_GUIDE.md to the effect of what's recommended. |
Important to note that According to @Jakob3xD's finding, I do think we need 2 separate types
type: string
pattern: '\d+(\.\d+)?\s(b|kb|mb|gb|tb|pb)' The pattern will be ignored by the clients but our JSON Schema validator will use it to test it against the response schemas. Like @dblock said, we should have a section for dealing with Units for the Dev's Guide (This includes time units too). |
|
I guess we're back to |
What is the bug?
Coming from opensearch-project/opensearch-go#284 (comment), the spec contains both humanly readable and non-humanly-readable versions of many fields. Fields of type
_common:BysteSize
are no longer returned by the API as they got replaced by the same property suffixed with_in_bytes
pointing to type number.The core engine seems to do something clever about it. For example. These are added with
humanlyReadableField
. It looks like there still may be cases where you have a non-humanly-readable field, or are there?Similar issue for
component/schemas/_common:Percentage
. It is alsooneOf
fornumber
orstring
. This is used for the cluster health endpoint. Which returns the value as number for yaml and json.What is the expected behavior?
Figure out whether non-humanly-readable fields are still possible, when they were deprecated/removed, either annotate them with
x-version-*
or delete them if they never existed in the OpenSearch fork.The text was updated successfully, but these errors were encountered: