These are chat archives for DataBrewery/cubes

13th
Mar 2017
Stefan Urbanek
@Stiivi
Mar 13 2017 03:12
If you ever wondered what you can pass as drilldown argument to aggregate(), then this is it (I’ll be adding more as they are discovered).
# Non-intuitive type that can be passed as drilldown to the browser's `aggregate()` function:
#
_DrilldownType = Union[
    Drilldown,
    Dict[str, Union[Dimension, str]],
    List[
        Union[
            str,
            DrilldownItem,
            Dimension,
            Tuple[
                Union[Dimension, str],
                Union[Hierarchy, str],
                Union[Level,str]
            ]
        ]
    ]
]
we can’t have those
Abbas Mashayekh
@martianboy
Mar 13 2017 14:12
@Stiivi I'm removing cube from cell as per https://github.com/DataBrewery/cubes/blob/2.0/cubes/query/cells.py#L301
Any suggestions where it might have a non-trivial impact?
Stefan Urbanek
@Stiivi
Mar 13 2017 15:28
@martianboy there are few places which might need a way to pass the cube, for example in query/browser.py
Thanks for the PR #407, will go through it later today
Abbas Mashayekh
@martianboy
Mar 13 2017 15:31
@Stiivi Thanks. I'll check whether query/browser is functioning properly with cube removed.
Stefan Urbanek
@Stiivi
Mar 13 2017 15:33
Looking at your removal of Unions (as needed by your change), we might need to rething the cell/cuts whether they contain references to dimensions or just plain strings and all functionality that requires dimension object be moved somewhere else. Let me thinkg about this one and chat a bit later.
I’m leaning towards the Cut(“date”, …) pattern
Abbas Mashayekh
@martianboy
Mar 13 2017 15:35
Yeah. Here I assumed all Cuts contain references to dimensions and it's the caller's responsibility to pass the proper Dimension object.
Stefan Urbanek
@Stiivi
Mar 13 2017 15:42
I was thinking making it light weight object that it can be easily created manually or converted from other (external) representation and applied to cubes with similar dimensions.
What is your opinion?
Stefan Urbanek
@Stiivi
Mar 13 2017 15:47
(Removal of cube was needed for drillacross #273)
Stefan Urbanek
@Stiivi
Mar 13 2017 16:34
Also related: few days ago I created #401 (Change all model/browser object getters of named objects accept only string), but more I look at it I have a feeling we need two kinds of interfaces: one internal which is with object references and one around that with strings. It is good to have both, but definitely not as it is right now.
Stefan Urbanek
@Stiivi
Mar 13 2017 16:45
the problem is, that current implementation the "string" arguments are safer than the Dimension/$OBJECT arguments: they are being fetched when they are needed with structure that is assured to be valid within the Cube query context. Whereas if passing a Dimension object nothing is stopping me from passing a differently configured dimension (different attributes, hierarchies, levels, ...) from some other cube.
The question is, how to centralize the conversion from references-by-name to objects? Some kind of "CubeQueryContext" is needed.