Add support for aliasing dimensions/measures

[philippefutureboy]

Is your feature request related to a problem? Please describe.

At our company, we use Cube.js internally as part of our data pipeline and load process. A common manipulation in this case for tidying up the result from the cubejs.load method is to rename the fields to a more concise alias so that the next person in the development pipeline has an easier time going about reading the data.

More specifically, we generate PDFs out of result from Cube.js, and there is no benefit for our frontend developer to know the full name of the variable requested via the query, so we manually alias the fields by using pandas and renaming the columns of the DataFrame using a mapper object.

The ability to alias directly in the query file would centralize the query language in a single file rather than having a json file and then load the result in pandas and rename the columns using .rename with a mapper dictionary. It would increase convenience and ease the design of a more decoupled data model.

Describe the solution you'd like

Support aliasing via a syntax or another in the query file:

Syntax 1

{
  measures: [
    ["very_long_name.property_name", "alias_name"]
  ]
}

Syntax 2

{
  measures: [
    { key: "very_long_name.property_name", alias: "alias_name" }
  ]
}

Babel-config-like syntax:

{
  measures: [
    ["very_long_name.property_name",  { alias: "alias_name" }],
    "very_long_name.prop_not_aliased"
  ]
}

Open to suggestions

Describe alternatives you've considered As described above.

[philippefutureboy]

Additional use-case:

When using lodash.get, the dot notation confuses lodash.get in thinking that the path is ['very_long_name', 'property_name'] rather than ['very_long_name.property_name']. The alternative is to use ramda's path function and provide an array rather than a parseable string.

Adding support for aliasing could provide a viable alternative to this issue as well.

[paveltiunov]

@philippefutureboy Thanks for posting this! I'll make it available for community contributions for now and see if others have similar use cases.

Everyone, please feel free to post comments about your use cases and upvote this issue.

[JoshMentzer]

We do this currently in our front end, allow people to rename measures and dimensions; just added an 'alias' key-value pair object to the query object which we strip prior to actually submitting to cube and then use again during visualization to replace column headers or series names, etc. Would definitely use the functionality if it was base.

[philippefutureboy]

That's essentially what I do as well Python-side :)

[iiq374]

This is definitely an issue when using Dynamic Schema where capitalised field values can appear in the Measure name

[rpaik]

Closing this issue as this can now be addressed with Views.