[5.2] Stabilized table aliases for self joins by adding count

[JeroenVanOort]

In order to improve query cacheability.

---

Fixes #13353.

[GrahamCampbell]

No need to hash that value?

[JeroenVanOort]

The only reason to hash is in case someone has tables like 'self_1', 'self_2', etc.

[GrahamCampbell]

how is the hash anymore resistant?

[GrahamCampbell]

maybe just call it laravel_reserved_1

[JeroenVanOort]

I think it's less likely for someone to have a table like 'self_c4ca4238a0b923820dcc509a6f75849b' than 'self_1'. The same reason why it was used in the first place, I assume; I just left it in.

Sure, the prefix could be changed to 'laravel_reserved_' to avoid this all together.

[taylorotwell]

Holding off on this.

[GrahamCampbell]

@taylorotwell What about for 5.3?

[JeroenVanOort]

@taylorotwell So what do I do now? I'd really like to have this merged in some shape or form. I guess you want to have a good look at this before merging and I get that, but closing the PR isn't very motivating for me.

[JeroenVanOort]

@GrahamCampbell Could we please look at this once more?

[taylorotwell]

Will re-open for reconsideration.

[GrahamCampbell]

@GrahamCampbell Could we please look at this once more?

Not upto me. Upto @taylorotwell. ;)

[JeroenVanOort]

Benchmarks for this request are difficult in the sense that this change has it's largest effects on long, more complicated queries on data that doesn't change by the second (in which case caching isn't helpful anyway), which I can't easily replicate in code I can share.

The most simple scenario is making a list of children that have a parent: in the current situation the generated table alias is different every time the query is executed and thus can't be cached. In the situation requested the alias will be the same every time, so it can be cached by the database system itself. On these simple queries, I've seen the query time halved, but they didn't take very much time to run anyway.

What you'll have to take my word for, is that I observed the time taken to execute a longer query drop from about 350ms to 1.1ms by simply executing the same thing twice (on a MySQL server that is set up to support caching, Homestead doesn't by default). For one project I'm working on, the page load time (as reported by the debug bar) goes down from ~500ms to just ~160ms, after the query has been cache by the first page load.

As far as I know, this change doesn't break anything; it just enables the database engine do it's caching job.