feat: sort selected columns & expands before formatting sql

[PDT42]

Reopens #1330 after it was reverted due to it causing failing tests in the base cds package.

[patricebender]

I was always under the impression, that the order of columns matters for users of our services. Why else do we have mechanism in place, which guarantee stable column order, like the smart wildcard?

The cds-compiler and cqn4sql have built-in logic to adhere to this principle. The rules can be summarized with the following case:

entity E {
  a : String;  b : String;
  c : String;  d : String;
};

entity After  as select from E { *, 1 as b, 2 as c    }; // a, b, c, d
entity Before as select from E {    1 as b, 2 as c, * }; // b, c, a, d
entity Around as select from E { 1 as b,  *,  2 as c  }; // b, a, c, d

entity Excluding as select from E { *, 2 as c  } excluding { c }; // a, b, d, c

→ this also goes for nested projections

please also see the sophisticated test suite, which makes sure that the cap-js database services adhere to those rules:

cds-dbs/db-service/test/cqn4sql/wildcards.test.js

Line 99 in d7f9094

it('MUST respect smart wildcard rules -> structure replacement before star', () => {

[johannes-vogel]

with OData's $select clause this is exposed to the end user who can easily construct a different order to exhaust the execution plan cache. If the order in CSN is stable, we can also use that order.

[BobdenOs]

@johannes-vogel the order in the examples are already all different from one another.

@patricebender the source of the problem is $select on the protocol level. Which allows end users to determine the column order. There is no problem with the order of the columns as they are in the cqn. It is only a problem with the order of the columns in the SQL statement.

Additionally no matter what the order of the columns are at any point in time. The properties in the returned objects are sorted based upon the principles of the ecma script spec. So if people expect the order of the properties of the results to match the order of their column definitions. This can't be true depending on their column names.