Bring back support for generating inline_cast.json for kibana #139807
Conversation
This is still using the old format. There is also an operators/cast.json file which could be extended to provide the same information in a more consistent way with the rest of the operators.
craigtaverner
added
>docs
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
|
Pinging @elastic/core-docs (Team:Docs) |
ℹ️ Important: Docs version tagging👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version. We use applies_to tags to mark version-specific features and changes. Expand for a quick overviewWhen to use applies_to tags:✅ At the page level to indicate which products/deployments the content applies to (mandatory) What NOT to do:❌ Don't remove or replace information that applies to an older version 🤔 Need help?
|
ivancea
left a comment
ivancea
left a comment
There was a problem hiding this comment.
Thanks Craig! Looks good. The comments are minor nits, so feel free to treat them as such!
| "geohash" : "to_geohash", | ||
| "geohex" : "to_geohex", | ||
| "geotile" : "to_geotile", | ||
| "int" : "TO_INTEGER", |
There was a problem hiding this comment.
nit: Can we normalize them to lowercase? I know you're not touching its generation here, but I wonder if there's some hidden issue behind that
There was a problem hiding this comment.
I also was surprised by this, but as you said I'm not touching the actual generating code, so I thought to leave this alone for now.
There was a problem hiding this comment.
A quick investigation, and this seems to come from the EsqlFunctionRegistry.nameSurrogates, which uses upper-case for TO_IP, TO_LONG and TO_INTEGER. We could fix that, but it seems out of scope for this PR.
There was a problem hiding this comment.
I just threw in an extra toLowerCase
| try (XContentBuilder report = new XContentBuilder(JsonXContent.jsonXContent, Files.newOutputStream(file))) { | ||
| report.humanReadable(true).prettyPrint(); | ||
| report.startObject(); | ||
| try (XContentBuilder report = JsonXContent.contentBuilder().humanReadable(true).prettyPrint().lfAtEnd().startObject()) { |
There was a problem hiding this comment.
nit: Can we have the startObject() out of the try? To make it more readable. Same for endObject() at the end.
Even if every method returns the same object this feels like a misuse of the chaining.
The humanReadable() and prettyPrint() could too, but they're not structurally relevant for the json, so whatever
There was a problem hiding this comment.
I actually inherited this pattern from the existing code for generating kibana definition files, but changed it to your suggestion because I agree with the improved visual balance of things.
…search into kibana_inline_cast
3 participants
This is still using the old format. There is also an operators/cast.json file which could be extended to provide the same information in a more consistent way with the rest of the operators. But for now this was the simplest change to get kibana unblocked.
The reason it was disabled was just that it used the wrong path, after the change to DocsV3. So this fix just wires it into the DocsV3Support class, so it will use the right paths going forward. A better change would be to get the operators/cast.json file to add all this information into the parameters list. But that is more work (both for us and for Kibana).