Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix milestones with too many repos #10186
This is my wild attempt of fixing #9841 to (hopefully) bring the release of 1.11.0 a little closer.
Just like the problem in #9755, we're attempting queries with too many parameters. This should be solvable by means of rewriting the query, but I found it very difficult in this case, so I attempted a different way instead:
So the concept is, instead of using the
To be honest, I just wanted to test the waters on using temporary tables, which I believe could prove useful in the future. This works just fine in all database engines, so in that regard I think it's a success.
There is room for improvement (for example, the temporary tables could be managed by xorm), but for the time being I'd like to hear your reactions.
@@ Coverage Diff @@ ## master #10186 +/- ## ========================================= Coverage ? 43.4% ========================================= Files ? 577 Lines ? 79715 Branches ? 0 ========================================= Hits ? 34603 Misses ? 40837 Partials ? 4275
@zeripath temp tables are used internally by the engines to perform sub-queries, so they are a pretty standard resource. They're also normally held only in memory. I've never heard of them causing problems. I'll look into it. Anyway, how many temp tables can there be? It's never in the hundreds or thousands, since we'd be creating one or two per connection (they're disappear when the connection is released).
The unique number id I've implemented is for ruling out any chance of collision in case we need to use more than one table in the same request. It's a global counter only because it's easier for me than having one per-request.
@zeripath I've been digging around and I've found nothing relevant to us.
I've found this article regarding a potential problem regarding innoDB and temporary tables that don't fit in memory buffers (>16MB), but the cases mentioned are pretty extreme (like if we'b be constantly banging the server with queries on >200,000 repositories). Even more, the problem is not about explicitly created temporary tables but any kinds of temporary tables, like those created internally when we use subqueries, so making the temp table explicit would make no difference.
So I'd say in this case it's pretty safe.