Aggregated Attributes Behaviour

Aggregated Attributes Behaviour


I think I found an odd behaviour with aggregated columns.

In the following link ( on page 18, there is a note specifying this: “NOTE: It’s important to sort by the (green) PersonRoleId because it represents the aggregated column, that is part of the output, while PersonMovieRole.PersonRoleId refers to the original attribute that is suppressed from the output.

Sorting by an attribute that is not part of the output would have no effect.”

            I think the platform should warn about that, as it is almost impossible to know that without consulting the tutorials.

            Furthermore, let’s say we have the following dataset:

In the present tutorial, we are asked to create an aggregated attribute for a person’s full name, which leads to the following:

Now, let’s say I want to group by the ‘FullName’ attribute, which is presented by the following (i’ve cancelled the auto hide of the FullName column for the sake of the example):

Now, head to the Sorting tab to add a new sort. This is the presented window:

As you may see, there are 2 FullName attributes, but only one of them is an aggregated column (I believe), which leads to possible errors on querying the database, since only of them will be part of the query.

So, that is one possible problem, since non aggregate columns should not appear inside the box, when having a group by clause, avoiding missorts.

Now, something weird seems to be also happening, because If I change the name of the previously hidden FullName column, we end up with the following:

Now, the first column changed also its name, seeming to be the same column (which is not the case). Then, click to edit the first column’s name to this:

However, clicking it to edit a second time, triggers the column to go back to its original naming (the expected one):

I am not sure why this problem is happening, but I tested several times with no change.

That seems like an interface bug. The aggregate editor is still not in a state we'd want it to be...

Hi Tiago,

Sorry for the late reply.

As you note, we're currently displaying all possible attributes in the sorting dialog, which can lead to confusion when the Aggregate has groups, specially in the scenario you mention. I'll forward your feedback to the appropriate team, so that it can be reviewed in a future revision of the platform.

Regarding your second scenario, the rationale for the automatic rename is that both attributes will have the same value, so we expect that keeping the name in sync is the common case.

The third scenario is effectively a bug and will be forwarded to the appropriate team as well.

Thank you for the thorough feedback, it really helps!