[possible BUG]: "$::" syntax with derived fields not working

paolo_mapelli — Sat, 16 Nov 2024 04:26:57 GMT

Hi,

while trying to set up some measures using a derived field (more precisely, one of those from "autoCalendar", generated by new app wizard) in a set analysis expression I came up to a possible bug.

Let's take "Month" as example. In autoCalendar data load script it is defined as [myDate.autoCalendar.Month], where "myDate", of course, is a date type field from my database and included in "DERIVE FIELDS FROM FIELDS" section of autoCalendar script.

For testing purposes I defined a "test_Month" field in data table load script as "Month(myDate)"

So, I have [myDate.autoCalendar.Month] and [test_Month] dimensions, defined in the same way and valued with same values, both acting on default state.

Then I placed a flat table (with its alternate state property left unchanged), added both above dimensions and defined 4 measures:

Sum({[Competitive Set]<,PY={'0'},[test_Month]=$::[test_Month]>}Revenue)
Sum({<,PY={'0'},[test_Month]=$::[test_Month]>}Revenue)
Sum({[Competitive Set]<,PY={'0'},[myDate.autoCalendar.Month]=$::[myDate.autoCalendar.Month]>}Revenue)
Sum({<,PY={'0'},[myDate.autoCalendar.Month]=$::[myDate.autoCalendar.Month]>}Revenue)

"Competitive Set" is an alternate state defined in my app and PY is another dimension. I used "$::" syntax to propagate filtering on dimension from default state to alternate state.

This is flat table output after data load and selection of two comparing sets:

As you can see, last two measures are always zero, and that's the main issue, whilst first two shows correct values.

Now, I select "gen" from "test_Month":

Correct behaviour on first 2 measures. Filter on "test_Month" is propagated from default to alternate state.

Now, I select deselect "gen" from "test_Month" and select "gen" from "myDate.autoCalendar.Month":

Again, I have a correct behaviour on first 2 measures.

So, it seems that "$::" syntax is not working with derived fields, although expressions with their use are correctly evaluated (we have zeroes instead of nulls).

Paolo.

topic [possible BUG]: "$::" syntax with derived fields not working in App Development

[possible BUG]: "$::" syntax with derived fields not working