I forget how to fix this. When using Case when the...
# gd-beginners
d
I forget how to fix this. When using Case when the date field gets hidden.
m
just an idea, not sure if that is the problem - this seems to be CASE on the fact-level so there is no aggregation function and no way for the system to ahgregate the data to date granularity etc. So maybe add some SELECT SUM(...) around the whole metric?
d
That didn't solve the date part (but was also needed)
I think someone said you have to do a BY or ALL or something but can't recall (I already tried these)
m
If the system thinks that particular date field is not compatible with the metric, you can add
BY ALL DateDimension
to convince the engine it can be sliced by that date. It will remove the warning/error. But if it is not compatible in the model (i.e. if fact/ssid_start is not connected to Timestamp date) it won’t make it work “for real”.
d
Yes, all of those metrics are connected by a time stamp
I figured a way around it using max instead of case when
j
It is great the problem is solved. Recommendation for future use cases: It is important to think about dimensions at which condition as well as variants of metric definitions after THEN/ELSE shall be computed if you plan to use CASE WHEN. It is evaluated at empty dimensionality (not sliced by any attribute) if it is added as metric to insight which is not sliced by any attribute and whole formula is expected to return just one number. Aggregation function is needed to reduce facts at grain of a dataset to only single number (condition may lead to different result for each row). The BY rule is suggested to define at which granularity the CASE statement needs to be evaluated. E.g.
SELECT MAX(SELECT CASE WHEN {label/attr1}="val1" THEN {metric/M1} ELSE {metric/m2} END BY attr1)
the BY rule will tell engine to compute both metrics m1 and m2 grouped by attr1 and either value of m1 or m2 will be used for the result depending on specified condition which will be evaluated on the same grain (which will include attr1 even if it is not used in the visualization). MAX will be used as aggregation function in case metric is not going to be sliced by attr1. {dataset/dataset_id} can be used in BY rule to specify grain of a dataset. BY rule is even more important when THEN/ELSE contains a constant. Constant is just one number so BY rile will define at which grain will be evaluated the condition. In general I would recommend to specify always BY rule for CASE statement and fill there: • all attributes which are compared in the condition • dataset identifier if the condition uses facts of a dataset • attributes which define grain at which metric shall be computed if metric is used in the WHEN condition + aggregation function on top of it so that metric can be used at different grain than specified by the BY rule In many cases CASE WHEN is not needed and you can use for example arithmetics with multiple metrics where each of them uses different WHERE condition.