Query contains non-consecutive table aliases when tables are pruned #32757
Labels
area-query
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
type-enhancement
Milestone
Note: I do not think this is a bug
We generate table aliases based on the first character of the table name, followed by an incrementing counter for uniquification; aliases are thus generally consecutive (we even have DEBUG-only checks that attempt to validate this).
However, when a table gets pruned, that causes a "hole" in the alias numbering. For example, with the following contrived TPT query:
Full repro
... we generate the following SQL:
... with only [b], [b2] and [b5]. This is because ctx.Blogs generally causes 3 tables to be added (entire TPT hierarchy), but
COUNT(*)
causes the child tables to be pruned, isnce the only referenced property is in the root (Name).I do not really consider this a bug, but there's some effort in the code to maintain consecutive aliases. Fully maintaining that in all cases requires another pass to check and rewrite aliases, and that doesn't seem worth it.
The text was updated successfully, but these errors were encountered: