-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Support types table in lookup join docs #130410
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
Support types table in lookup join docs #130410
Conversation
|
🔍 Preview links for changed docs: 🔔 The preview site may take up to 3 minutes to finish building. These links will become live once it completes. |
|
Pinging @elastic/es-docs (Team:Docs) |
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
🔍 Preview links for changed docs |
| To obtain a join key with a compatible type, use a [conversion function](/reference/query-languages/esql/functions-operators/type-conversion-functions.md) if needed. | ||
|
|
||
| For a complete list of supported data types and their internal representations, see the [Supported Field Types documentation](/reference/query-languages/esql/limitations.md#_supported_types). | ||
| The list of unsupported fields includes all types not supported by {{esql}} as described in the [Unsupported Field Types documentation](/reference/query-languages/esql/limitations.md#_unsupported_types). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@craigtaverner I think this section is a little messy now, and technically this should be all part of the bulleted list
I suggest we revamp the Prerequisites section and use subheadings, and instead of prose/list items for the supported/unsupported types, perhaps a table would be a good alternative?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's an approach, in docsv3 syntax:
Prerequisites
Index configuration
Indices used for lookups must be configured with the lookup index mode.
Data type compatibility
Join keys must have compatible data types between the source and lookup indices. Types within the same compatibility group can be joined together:
| Compatibility group | Types | Notes |
|---|---|---|
| Integer family | byte, short, integer |
All interchangeable |
| Float family | half_float, float, scaled_float, double |
All interchangeable |
| Keyword family | keyword, text.keyword |
Text fields only as join key on left-hand side and must have .keyword subfield |
| Date (Exact) | DATE |
Must match exactly |
| Date Nanos (Exact) | DATE_NANOS |
Must match exactly |
| Boolean | boolean |
Must match exactly |
For a complete list of all types supported in `LOOKUP JOIN`, refer to the [`LOOKUP JOIN` supported types table](/reference/query-languages/esql/commands/processing-commands.md#esql-lookup-join).
To obtain a join key with a compatible type, use a [conversion function](/reference/query-languages/esql/functions-operators/type-conversion-functions.md) if needed.
Unsupported Types
In addition to the {{esql}} unsupported field types, LOOKUP JOIN does not support:
VERSIONUNSIGNED_LONG- Spatial types like
GEO_POINT,GEO_SHAPE - Temporal intervals like
DURATION,PERIOD
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or perhaps we can lose the overview table/list entirely and delegate to the new autogenerated table?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
anyways just food for thought, I think the data type compatibility info should be a standalone section in any case, whether it's under prerequisites or not :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I incorporated your changes. I agree it makes things look more similar with two tables. But I think users might find both places independently, so it is not too bad to have two ways. The generated one is more up-to-date. I did make one fix to your table, because we can join between integers and float now too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is neat, thanks @craigtaverner !
Only minor comments from me :)
| @@ -0,0 +1,77 @@ | |||
| % This is generated by ESQL's AbstractFunctionTestCase. Do not edit it. See ../README.md for how to regenerate it. | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: this is generated from a different class, actually
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kind of think the increase in entropy from the fix is not worth it. Perhaps if we have more tests that do this...
docs/reference/query-languages/esql/_snippets/commands/types/lookup-join.md
Outdated
Show resolved
Hide resolved
| For important information about using `LOOKUP JOIN`, refer to [Usage notes](../../../../esql/esql-lookup-join.md#usage-notes). | ||
| :::: | ||
|
|
||
| :::{include} ../types/lookup-join.md |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: would move that below the examples, this is a bulky little table :)
That looks inconsistent with like/rlike - but actually, that one has a duplicate Supported Types table and if we remove the upper one, we'd again have the supported types neatly below the examples!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I've made the types table concise, does it look better? Having it above the examples is consistent with all the functions and operators docs, so I had hoped to keep it that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, you're right. I also re-checked like/rlike's type tables in the WHERE documentation, and they are actually consistent as well. Let's keep it.
| public void testOutputSupportedTypes() throws Exception { | ||
| Map<List<DataType>, DataType> signatures = new LinkedHashMap<>(); | ||
| for (TestConfigs configs : testConfigurations.values()) { | ||
| if (configs.group.equals("unsupported") || configs.group.equals("union-types")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should use static string constants rather than typing out unsupported and union-types verbatim.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, but perhaps out of scope, since this test uses string literals like this in many places and I think they could all be fixed together. Perhaps moved into an enum, and use a switch somewhere to assert none are left out?
...esql/src/internalClusterTest/java/org/elasticsearch/xpack/esql/action/LookupJoinTypesIT.java
Show resolved
Hide resolved
Co-authored-by: Alexander Spies <[email protected]>
…er/elasticsearch into esql_lookup_join_types_table
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @craigtaverner !
| | byte | half_float, float, double, scaled_float, byte, short, integer, long | | ||
| | date | date | | ||
| | date_nanos | date_nanos | | ||
| | double | half_float, float, double, scaled_float, byte, short, integer, long | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, much better now in this format!
|
|
||
| | Compatibility group | Types | Notes | | ||
| |------------------------|-------------------------------------------------------------------------------------|----------------------------------------------------------------------------------| | ||
| | **Numeric family** | `byte`, `short`, `integer`, `long`, `half_float`, `float`, `scaled_float`, `double` | All compatible | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bikeshed: this is nice, but may get stale as it's duplicating the more explicit table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely, but it's much nicer than list or prose, so let's keep an eye and make sure it doesn't become stale, otherwise we could just render the full table here too and be 100% in sync :)
* Support types table in lookup join docs * Don't show a results column in the join types * Make LOOKUP JOIN types table more compact * Update docs/reference/query-languages/esql/esql-lookup-join.md Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Alexander Spies <[email protected]>
|
Backport to 9.1 in #130537 |
* Support types table in lookup join docs * Don't show a results column in the join types * Make LOOKUP JOIN types table more compact * Update docs/reference/query-languages/esql/esql-lookup-join.md Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Alexander Spies <[email protected]>
…#130537) * Support types table in lookup join docs (#130410) * Support types table in lookup join docs * Don't show a results column in the join types * Make LOOKUP JOIN types table more compact * Update docs/reference/query-languages/esql/esql-lookup-join.md Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Alexander Spies <[email protected]> * Fix the ESQL docs for the null predicates (#130440) Fix null predicates docs * This also includes moving the note above the examples in the Kibana inline docs. * Add missing knn docs * Refine newlines in kibana docs --------- Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Alexander Spies <[email protected]>
…lastic#130410) (elastic#130537) * Support types table in lookup join docs (elastic#130410) * Support types table in lookup join docs * Don't show a results column in the join types * Make LOOKUP JOIN types table more compact * Update docs/reference/query-languages/esql/esql-lookup-join.md Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Alexander Spies <[email protected]> * Fix the ESQL docs for the null predicates (elastic#130440) Fix null predicates docs * This also includes moving the note above the examples in the Kibana inline docs. * Add missing knn docs * Refine newlines in kibana docs --------- Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Alexander Spies <[email protected]>
|
Backport to 9.0 in #130613 |
…#130613) * [9.1] Fixes to null-predicates and lookup-join docs (#130440 #130410) (#130537) * Support types table in lookup join docs (#130410) * Support types table in lookup join docs * Don't show a results column in the join types * Make LOOKUP JOIN types table more compact * Update docs/reference/query-languages/esql/esql-lookup-join.md Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Alexander Spies <[email protected]> * Fix the ESQL docs for the null predicates (#130440) Fix null predicates docs * This also includes moving the note above the examples in the Kibana inline docs. * Add missing knn docs * Refine newlines in kibana docs --------- Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Alexander Spies <[email protected]> * Fix Null predicates after cherry-pick * [DOCS] Update ES|QL generated docs to consistently use the `applies_to` metadata (#128576) - Add PREVIEW annotations to all preview functions - Update docs generation logic to use annotations instead of preview boolean * Changed stack: ga 9.1 to stack: coming in multiple places - Match.java: Updated the options parameter description - MultiMatch.java: Updated the options parameter description - ToLower.java: Reformatted parameter description and updated version annotation - ToUpper.java: Removed the appliesTo annotation entirely and reformatted parameter description - updated applies_to annotations to specify both preview 9.0.0 and ga 9.1.0 lifecycle stages - added version-specific documentation examples with applies_to markers for ga 9.1.0 features - enhanced to_lower and to_upper functions to indicate support for multi-valued expressions in ga 9.1.0 - added version guards around function parameters and descriptions using applies_to syntax - updated function parameter descriptions to indicate ga 9.1.0 availability for named parameters - use detailedDescription + and fix match_phrase applies_to syntax - strip inline applies_to from kibana docs - update roundto, matchphrase lifecycles - fix match named params info - various spatial functions are preview - unsigned long is preview - update qstr - Update TO_LOWER/TO_UPPER parameter descriptions for clarity - hide spatial functions per #129839 - added `stack: ga 9.1.0` blocks to match_phrase.md and qstr.md examples - simplified term.md version from `preview 9.0.0` to just `preview` - added `applies_to = "stack: ga 9.1.0"` to matchphrase and querystring java annotations - removed version `9.0.0` from term function annotation - deleted unused `makeCallout()` and `appendLifeCycleAndVersion()` methods Co-authored-by: elasticsearchmachine <[email protected]> Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Nik Everett <[email protected]> * First round cleanup of docs after cherry-picking Includes partial support for the grammer fix to the header comment. * Second round, just replacing `no` with `not` * Fix lookupjointypes test after backport --------- Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Alexander Spies <[email protected]> Co-authored-by: elasticsearchmachine <[email protected]> Co-authored-by: Liam Thompson <[email protected]> Co-authored-by: Nik Everett <[email protected]>
The LOOKUP JOIN docs are very brief in their description of supported types, saying only that the fields must be compatible. This PR tries to fix that by:
LookupJoinTypeITtest, and so automatically updated