You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@druid.apache.org by GitBox <gi...@apache.org> on 2019/06/27 00:23:40 UTC

[GitHub] [incubator-druid] clintropolis opened a new pull request #7973: expression language array constructor and sql multi-value string filtering support

clintropolis opened a new pull request #7973: expression language array constructor and sql multi-value string filtering support
URL: https://github.com/apache/incubator-druid/pull/7973
 
 
   This PR adds a new function `array(expr1, ... ,exprN)` to allow constructing expression arrays, as well as a corresponding druid-sql `ARRAY` function which does the same. These functions were both added in the service of adding sql functions that allow filtering multi-value dimensions as expressively as native Druid queries, `MV_CONTAINS` and `MV_OVERLAP`, where the `MV_` stands for 'multi-value'. 
   
   ```SQL
   SELECT dim3 FROM druid.numfoo WHERE MV_CONTAINS(dim3, ARRAY['a','b']) LIMIT 5
   ```
   
   I've actually defined these as aliases for `ARRAY_CONTAINS` and `ARRAY_OVERLAP`, since both sets of these functions are driven internally by `array_contains` and `array_overlap` respectively, so they can share operator conversion implementations. The reasoning for the dupe naming is: most of the Druid expression array functions pose no problem with accepting either `VARCHAR` or `ARRAY` typed input, but the functions which _produce_ an array expression will need different implementations for differently typed outputs (`VARCHAR` for `MV_`, and `ARRAY` for `ARRAY_`), so this is done to encourage using the `MV_` prefix for multi-value string dimensions, and reserving `ARRAY_` for if/when we implement true array types natively in Druid. I have not documented any of the sql support for multi-value string dimensions yet, so there is still some wiggle room here as I continue to fill out the other functions.
   
   In the process of these changes, I've modified the output of `array_contains` and `array_overlap` expressions to return 1 or 0, instead of using `ExprEval.bestEffortOf` with a boolean input, which was ending up as `"true"` or `"false"`, which for `ExprEval` is never true. This allows these functions to actually work in filters.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org