Remove ambiguity in GetUserRepositories SQL

[btrepp]

This includes all columns of the repository table in the group by clause
Certain databases will attempt to infer the other columns eg.
https://dev.mysql.com/doc/refman/5.7/en/group-by-handling.html

As some databases supported by xorm don't have the ability to do this
we include every column in the group by clause, this should work the
same assumining repository.id is unique.

This pull request will fix issues viewing the organisation page with #383.

[tboerger]

The indentation looks far too much and beside that the quoting is not database agnostic.

[btrepp]

Sorry about the indentation, i'm not 100% what whitespace characters are used in these files,I just replicated the whitespace characters that existed in vim, which looks fine in vim, but seems odd here. I will fix this.

Are you happy with the approach taken?. I think I would prefer to improve it to use some sort of reflection on the Repository struct, but would like to know if the maintainers think this is a good strategy to fix this issue before I spend too much time on it.

[tboerger]

I'm not really happy with this kind of query, but I can't remember real alternatives in mssql beside sub queries.

[btrepp]

I'm not thrilled with it myself, but its what I'm running currently to have gitea usable. Nested selects/sub queries is how I would usually solve this, and would be database agnostic, but from what I can tell xorm doesn't really support them (which makes sense, it should be generating queries). So maybe the issue is upstream with xorm?.

Options I've thought to fix this are.

1. Group/or select MAX() columns we only want, the motivation for all columns in the PR is that I don't know exactly how these data structures are used, so its safer to fully populate it
2. Build the group by/select via reflection, I began working on this, but you would need to access xorms struct-column mapper to make sure you got the correct table naming (it appears gitea uses the snake_case mapper, but it would be better to automatically use whatever xorm is using).
3. RAW SQL that is database agnostic, which wouldn't be too difficult... except that gitea is paging the results and MSSQL uses completely different literals for doing that.
4. Do a nested select, but do it in two stages to make xorm happy, this could work, but would involve pulling out all of the users team_repos, much like how the users teams is pulled out. I would be concerned about the performance of doing this when a user is involved in many repositories/teams. It would render the performance gain of paging that query redundant.
5. Deciding to abandon MSSQL and only supported databases that can work around more ambiguous SQL queries.

[tboerger]

I'm totally fine with multi database support, and it's also good that you have skipped the reflection way.

I'm just thinking about two queries. One fetching only the unique ids, one to fetch the real repositories.

[btrepp]

I've updated it to do in in two queries like you suggested. I'm not sure whether this function is becoming a bit mammoth now though.

[tboerger]

@lunny suggestions?

[lunny]

I will give it L-G-T-M after I tested it. @tboerger

[tboerger]

Got conflicts

[lunny]

LGTM

[appleboy]

LGTM