You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metamodel.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2015/11/02 22:59:27 UTC

[jira] [Commented] (METAMODEL-195) Scalar function to get key from a MAP type field

    [ https://issues.apache.org/jira/browse/METAMODEL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14986136#comment-14986136 ] 

ASF GitHub Bot commented on METAMODEL-195:
------------------------------------------

GitHub user kaspersorensen opened a pull request:

    https://github.com/apache/metamodel/pull/70

    METAMODEL-195 - a MAP_VALUE function

    This PR attempts to fix METAMODEL-195, the addition of a MAP_VALUE function which takes a string parameter to tell which value from within a map you wish to get. It's syntax is like this: ```MAP_VALUE('path.to.value', column)```
    
    There is also support for a query parser shorthand syntax where you select like this: ```column.path.to.value```
    
    It only works on MAP type columns.
    
    Point to especially consider: Since this is the first function which involves parameters, I ended up also doing some redesign of the ScalarFunction interface. I initially built it so that parameters was part of the MapValueFunction instance and thus you would need to instantiate the function for each parameter set you have. This worked kinda well just until I came to the point of parsing and printing the function as SQL. The trouble here was that if the interface did not reveal the parameters in any way then automating the printing etc. wasn't possible either. I am a bit unhappy about changing the interface already since it was launched in MetaModel 4.4.0, but figure we kind of need it if we want to support functions like this. I actually think that the interface I ended up with here could be further improved, but this was the first stab to get your feedback.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/kaspersorensen/metamodel METAMODEL-195/map-value-function

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/metamodel/pull/70.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #70
    
----
commit 6bfbfa1d82b573d007193593219d6eb6ec38f466
Author: Kasper Sørensen <i....@gmail.com>
Date:   2015-10-22T19:33:26Z

    METAMODEL-195: Added MAP_VALUE function

commit cb82939b6892a480f4e537277c081bb052aee6dc
Author: Kasper Sørensen <i....@gmail.com>
Date:   2015-10-23T15:39:23Z

    METAMODEL-195: MAP_VALUE function special short-hand syntax

commit 8f603edfcea419fdf5a6965b3a7f14f4bee61cfa
Author: Kasper Sørensen <i....@gmail.com>
Date:   2015-11-02T21:47:34Z

    METAMODEL-195: Implemented parsing and keeping of params in select item

commit 04c00e67192ffd4238cf5250e358b18934bca6f7
Author: Kasper Sørensen <i....@gmail.com>
Date:   2015-11-02T21:52:36Z

    Merge branch 'master' into METAMODEL-195/map-value-function
    
    Conflicts:
    	core/src/main/java/org/apache/metamodel/query/SelectItem.java
    	core/src/main/java/org/apache/metamodel/query/parser/SelectItemParser.java
    	core/src/test/java/org/apache/metamodel/query/parser/QueryParserTest.java

----


> Scalar function to get key from a MAP type field
> ------------------------------------------------
>
>                 Key: METAMODEL-195
>                 URL: https://issues.apache.org/jira/browse/METAMODEL-195
>             Project: Apache MetaModel
>          Issue Type: Improvement
>            Reporter: Kasper Sørensen
>
> Now that we have support for scalar functions, and we also support a host of key/value or document oriented datastores, I think it would be really natural to support a function for getting a value inside a map.
> Example:
> {code}
> SELECT MAP_VALUE(address, 'street') FROM contacts
> {code}
> Ideally the function would allow for a full "path" of keys so that you could have maps-within-maps and so on.
> {code}
> SELECT MAP_VALUE(address, 'homeaddress.street') FROM contacts
> {code}
> Even more ideally we would also add a bit of query parser logic to allow expressing the path as part of the operand itself:
> {code}
> SELECT address.homeaddress.street FROM contacts
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)