fix(schema-compiler): Avoid ambiguous dimension column mappings for ClickHouse queries

[dragosrep]

Check List

• Tests have been run in packages where changes made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet

This fixes #9383

The root cause of this issue is the ClickHouse server that sometimes includes the table prefix in the column name when returning the result set. For example, the query:

SELECT
    q_0.id,
    q_0.cat,
    value_0,
    value_1
FROM  (
    SELECT 1 as id, 'a' as cat, 100 as value_0
) q_0
INNER JOIN (
    SELECT 1 as id, 'b' as cat, 200 as value_1
) q_1 ON q_0.id=q_1.id

returns:

,while:

SELECT
    q_0.id,
    q_0.cat,
    value_0,
    value_1
FROM  (
    SELECT 1 as id, 'a' as cat, 100 as value_0
) q_0
INNER JOIN (
    SELECT 1 as id, 'b' as cat, 200 as value_1
) q_1 ON q_0.id=q_1.id
INNER JOIN (
    SELECT 1 as id, 'c' as cat, 300 as value_2
) q_2 ON q_0.id=q_2.id

has the following result set:

Similarly, SQL result sets from complex analytics queries with cube joins sometimes end up with column names having the q_0 prefix, leading to an error when trying to map them to a dimension.

The overriden dimensionColumns explicitly sets the column name to avoid this problem. Without it, one of the two provided integration tests fails.

[KSDaemon]

I think checking for cubeAlias inside template string (cubeAlias && ${cubeAlias}. || '') is not necessary, as you can get here only if cubeAlias === 'q_0'

Suggested change

	return this.dimensionAliasNames().map(alias => `${cubeAlias && `${cubeAlias}.` || ''}${alias} ${alias}`);
	return this.dimensionAliasNames().map(alias => `${cubeAlias}.${alias} ${alias}`);

[KSDaemon]

I'm trying to get what the difference between this and impl in baseQuery... Okay, I see.. You add another plain alias without cubeAlias... What if there are more query members from other subqueries with the same plain alias? It seems that it leads to ambiguity, and the query will fail... Nope?