| 2 | | > Ömer, |
| 3 | | > |
| 4 | | > > My initial attempt was to use Query.bump_prefix but as you told it threw an error. |
| 5 | | > |
| 6 | | > The error you encountered is due to `bump_prefix` requiring some adjustments. The alias merging algorithm that `Query.combine` uses requires that both query share the same initial alias in order to work otherwise you'll get a `KeyError`. You'll want to find a way to have `bump_prefix` adjust all the aliases but the initial one so it can still be used as the merge starting point. |
| 7 | | > |
| 8 | | > --- |
| 9 | | > |
| 10 | | > Vishal, |
| 11 | | > |
| 12 | | > > Here, I am randomly choosing an uppercase letter as the first character of alias, this returns different aliases, but a test_case is failing with this approach, with the following traceback. |
| 13 | | > |
| 14 | | > Choosing a random initial alias will bring more bad than good as not relying on `alias_prefix` will cause undeterministic failures across the board. There are reasons why the prefix is used and bumped only on conflic; it makes reasoning about possible collisions easier. |
| 15 | | > |
| 16 | | > > In 2nd approach, I have rotated the alias_prefix in a circular manner from T(class variable alias_prefix has value T) to Z, then from A to Z, and so on, and it also works on the above-attested code but fails five other test cases. |
| 17 | | > |
| 18 | | > This approach doesn't account for possible collisions with subquery aliases and will eventually collide once you've wrapped up around the 26 letter of the alphabet instead of using the Cartesian product approach. |
| 19 | | > |
| 20 | | > --- |
| 21 | | > |
| 22 | | > All of the required logic for preventing `alias_prefix` collisions already lives in `bump_prefix`, it's only a matter of adjusting it in order to allow it to be used in the alias merging algorithm of `combine`. |
| 23 | | |