{"action":"created","issue":{"url":"https://api.github.com/repos/DataBrewery/cubes/issues/245","labels_url":"https://api.github.com/repos/DataBrewery/cubes/issues/245/labels{/name}","comments_url":"https://api.github.com/repos/DataBrewery/cubes/issues/245/comments","events_url":"https://api.github.com/repos/DataBrewery/cubes/issues/245/events","html_url":"https://github.com/DataBrewery/cubes/issues/245","id":51752663,"number":245,"title":"Provide drill across","user":{"login":"grugnog","id":905689,"avatar_url":"https://avatars.githubusercontent.com/u/905689?v=3","gravatar_id":"","url":"https://api.github.com/users/grugnog","html_url":"https://github.com/grugnog","followers_url":"https://api.github.com/users/grugnog/followers","following_url":"https://api.github.com/users/grugnog/following{/other_user}","gists_url":"https://api.github.com/users/grugnog/gists{/gist_id}","starred_url":"https://api.github.com/users/grugnog/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/grugnog/subscriptions","organizations_url":"https://api.github.com/users/grugnog/orgs","repos_url":"https://api.github.com/users/grugnog/repos","events_url":"https://api.github.com/users/grugnog/events{/privacy}","received_events_url":"https://api.github.com/users/grugnog/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/DataBrewery/cubes/labels/enhancement","name":"enhancement","color":"DDDDDD"},{"url":"https://api.github.com/repos/DataBrewery/cubes/labels/%E2%AD%90%EF%B8%8F","name":"⭐️","color":"fef2c0"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2014-12-11T23:30:15Z","updated_at":"2015-01-13T05:43:08Z","closed_at":null,"body":"Right now to drill across, users need to be implement this logic as part of the analytics/reporting system, which is fine - but can be quite a bit of work in practice. It would be really convenient if there was a function that could assist with this.\r\n\r\nIn terms of architecture, it seems like this could perhaps be implemented as an additional layer on or beside the backend that could perform multiple queries and aggregate the results. This would make reuse easier (compared with having cubes viewer make multiple queries directly, for example).\r\n\r\nRough sketch of how this might work:\r\n`/cubes/<cube1>+<cube2>+.../<aggr-options>/<query>`\r\n\r\nThe <query> would potentially be any query that is accepted by the \"cube\" endpoint. The logic would probably first need to parse the query and validate that each cube has each of the dimensions used for that query (it would be nice if cubes didn't need to have identical dimensions, as in #169).\r\n\r\nThen the backend would perform the queries on each cube and aggregate the results. Assuming there are more than one way to aggregate the results (beyond just extra columns for each cube) having <aggr-options> argument might be useful to allow the user to tweak that.\r\n\r\nI can see more complex stuff like cross-tables that wouldn't fit the above pattern, but am not sure if it makes sense to try and include them (and if it does, if they could sensibly use this format without making it more complex for simple stuff)."},"comment":{"url":"https://api.github.com/repos/DataBrewery/cubes/issues/comments/69698376","html_url":"https://github.com/DataBrewery/cubes/issues/245#issuecomment-69698376","issue_url":"https://api.github.com/repos/DataBrewery/cubes/issues/245","id":69698376,"user":{"login":"Stiivi","id":71105,"avatar_url":"https://avatars.githubusercontent.com/u/71105?v=3","gravatar_id":"","url":"https://api.github.com/users/Stiivi","html_url":"https://github.com/Stiivi","followers_url":"https://api.github.com/users/Stiivi/followers","following_url":"https://api.github.com/users/Stiivi/following{/other_user}","gists_url":"https://api.github.com/users/Stiivi/gists{/gist_id}","starred_url":"https://api.github.com/users/Stiivi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Stiivi/subscriptions","organizations_url":"https://api.github.com/users/Stiivi/orgs","repos_url":"https://api.github.com/users/Stiivi/repos","events_url":"https://api.github.com/users/Stiivi/events{/privacy}","received_events_url":"https://api.github.com/users/Stiivi/received_events","type":"User","site_admin":false},"created_at":"2015-01-13T05:43:08Z","updated_at":"2015-01-13T05:43:08Z","body":"This feature can be indeed added to the SQL query generator, however it has to be refactored first. See reasons in [this post](https://groups.google.com/forum/#!topic/cubes-discuss/93rfWbPNPKY).\r\n\r\nAs for the API, my suggestion would be just to extend the original interface with one more argument: `across`. The `+` in list of cubes is interesting idea, but what would server say on `/cube/foo+bar+baz/model` instead of `.../aggregate`?\r\n\r\nMy suggestion would be: `/cube/foo/aggregate?across=bar,baz&drilldown=something` and in Python: `browser.aggregate(foo, drilldown=something, across=[bar,baz])`.\r\n\r\nHow does that interface sound?\r\n\r\nAs with joining, I'm not quite sure yet how difficult it would be to implement, but I'll just throw few pointers and notes here for future reference:\r\n\r\n* the [QueryBuilder](https://github.com/DataBrewery/cubes/blob/42b58b3296b57e34c2860b88a1b9502dfe94be94/cubes/backends/sql/query.py#L661) (to be dissolved, as described in the post linked above) will have to consider `SnowflakeSchema`s of other cubes as well\r\n* there should be something on top of the [`join_expression()`](https://github.com/DataBrewery/cubes/blob/42b58b3296b57e34c2860b88a1b9502dfe94be94/cubes/backends/sql/query.py#L335) that would take the already joined snowflakes\r\n"}}