Hello!
Recently, we’ve stumbled upon the following issue: we created a particular calculated field when defining the dataset, which shows up fine on the data preview and seems to be working properly. However, when you import the dataset into an analysis, the field doesn’t work anymore. We confirmed it by comparing the behaviour on some rows which were right during data prep.
Now, being more specific, the table structure relevant to the question is something like
| col_1 | col_2 | calc_field |
|:-----:|:---------:|:----------:|
| A | 1.0 | 1 |
| A | 3.0 | 3 |
| B | some text | |
| A | 8.0 | 8 |
| B | some text | |
where both col_1
and col_2
are stored with string data types, and the calc_field
represents our numerical (and troublesome) calculated field, defined as follows
ifelse({col_1}='A', parseInt({col_2}), null)
The sample table above is essentially what we see during preview in data prep, but, when attaching the dataset in an analysis, a quick table visual to check those fields yield the following picture,
| col_1 | col_2 | calc_field |
|:-----:|:---------:|:----------:|
| A | 1.0 | null |
| A | 3.0 | null |
| B | some text | null |
| A | 8.0 | null |
| B | some text | null |
In summary, that’s it.
We’ve tried searching similar questions here in the community, however, the underlying problems in all of those didn’t seem to be applicable in our case.
One thing we’d also like to mention is that we have a dataset coming from a relational database source (MySQL) that follows the exact same logic and everything works fine, both in data preparation and inside an analysis. This particular issue showed up in a dataset coming from an Athena source. SPICE query mode was used in all scenarios.
Thanks,
C.