Generate Unique alias for table names

[smitpatel]

resolves #3826
Presently it is code change only. If approaches looks right then I will update SQL generated for tests and add more test to verify this scenario.

[smitpatel]

@anpete @maumar

[maumar]

we could change this to work the same for one letter aliases as well as multi letter aliases, i.e.
currently we have:
a -> a0, a1, a2
bb -> bb0, bb00, bb000

we should aim for
bb -> bb0, bb1, bb2, bb3

[smitpatel]

updated.

[anpete]

Use named parameter to clarify false here.

[smitpatel]

@anpete - Updated with different approach. I checked few tests to verify that we are preserving user-defined names.

[maumar]

break those long lines into 2 separate ones, we usually do something like:

var innerSelectExpression
= handlerContext.SelectExpressionFactory.Create(handlerContext.QueryModelVisitor...)

[maumar]

we can probably change the base generated name from "subquery0" to "subquery", since it's being uniquefied anyway

[smitpatel]

Updated with feedback. Added some tests.

[anpete]

Or, currentAlias.Length == 0

[anpete]

@smitpatel Is it just that not all test changes have been reverted from the earlier approach? Because, if not, it looks like we are still unique-fying too much.

[smitpatel]

Updated with 1 more change which reduced changes required.
There are mainly 3 reasons for changes occurring

1. We are unique-fying across query model. Therefore if multiple SQL statements are executed aliases will be unique across all. Which was not the case previously.
2. Subquery aliases - During include processing when we generate a subquery for inner join, previously we used same alias as inner table. We are making it unique now.
3. Client Eval - If the query is using client eval then we visit the query model first time using alias names but fails to generate SQL out of it. So when we process query model again for client eval, they will use different aliases.

Most changes in tests look to be consequence of one of the above. If there is any particular test which seems to be unique-fy extra then point me to it and I will investigate it.

[smitpatel]

Update to above:
4. Subquery depth - Previously we used t + subquery depth as alias so that push down subquery gets different alias, now we are unique-fying it so we don't use depth anymore. Which changes it to start from t instead of t0 as before.

[anpete]

@smitpatel Thanks for the clear explanation. 1,2 & 4 are OK. Can you see if there is any easy fix to 3? Otherwise

[smitpatel]

For point 3 I tried looking into avoiding it. But we traverse the queryModel 2 times and both generate different SelectExpression. And we don't have any way to know what initiated QueryModelVisitor. The only way to do it without changing a lot of things in background would be to remove all generated aliases if client eval starts but it can have side-effects. So I did not attempt that way.