-
Notifications
You must be signed in to change notification settings - Fork 39
Description
Describe the bug
When adding an item with a property such as "sat:absolute_orbit": "10" (a string), the property remains as a string when the item is retrieved from the API, even though sat:absolute_orbit is defined as an integer type in queryables. While the property appears to be properly cast and indexed (and is searchable as integer), the returned properties field is not type-cast according to the queryables mapping. This means consumers of the API cannot rely on type consistency as defined in queryables - they may still receive string values instead of integers, despite the data model and queryables indicating an integer type.
To Reproduce
- Insert an item with a property like
"sat:absolute_orbit": "10"(string). - Ensure queryables define
sat:absolute_orbitas integer type. - Retrieve the item through the API.
- Observe that the returned property remains a string, not integer, even though it is indexed and searchable by integer value.
Expected behavior
Properties returned by the API should be cast according to queryables type definitions (e.g., integer, float) either:
- on insert (recommended), or
- at least on return when serving responses - ensuring the API delivers type-consistent data regardless of how it was originally submitted.
This guarantees consumers always receive data matching the types defined by queryables, even if the underlying _source is preserved as-is.
Additional context
Improving type-casting on properties according to queryables would reduce errors and eliminate ambiguity for API clients. This is particularly important when dealing with integrations or scripts that rely on type safety.