#3797 - Cleanup queries so can_arbitrary_groupby/remove_duplicate_rows
-
By Chris Graham
- Added
- 0 views
| Identifier | #3797 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Cleanup queries so can_arbitrary_groupby/remove_duplicate_rows |
| Status | Completed |
| Tags |
Roadmap: v11 (custom) |
| Handling member | Chris Graham |
| Addon | core_database_drivers |
| Description | In various places we use can_arbitrary_groupby and/or remove_duplicate_rows to strip out duplicated rows coming out of SQL queries.
This is because doing JOINs on tables will multiply up rows on the main table being queried, if the joined table has multiple matching records. For example, if you are using a JOIN to check group access to a category, and a user is in multiple groups with access, you'll get as many rows back as there are groups with access. We do it using JOINs because MySQL did not support subqueries until 4.1 in 2003. Webhosts are notorious for running old versions of MySQL, but at this point it would be shocking for a host to be running a version this old. So we should alter the DB drives to remove the concept of can_arbitrary_groupby (which is a non-compliant MySQL hack), and assume subquery support is always there (I think this is already done in v11). Then instead of JOINs to check things like category membership or group access, we use IN or EXISTS clauses in the queries, or subqueries that select a field value (parentheses). main_multi_content needs changes too. This currently doesn't use can_arbitrary_groupby/remove_duplicate_rows because of the complexity in this code. Instead it has it's own deduplication technique, and always reads records from offset 0, manually skipping records up until $start. |
| Steps to reproduce | |
| Related to | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
In many cases we are doing JOINs that can bind 0-to-many rows because we want to get some results back from the join. So we cannot simply switch to EXISTS or IN clauses.
A better solution is probably just to be more careful about what fields we SELECT, so that we're only selecting stuff covered in the GROUP BY clause. That will only work when we don't want to SELECT something we explicitly know might be duplicated up.
"Expression 28 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'cms.p.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by"
When doing "SELECT * FROM cms11_f_topics t JOIN cms11_f_posts p WHERE t.id=1 GROUP BY t.id;"
But this is fine:
"SELECT t.id FROM cms11_f_topics t JOIN cms11_f_posts p WHERE t.id=1 GROUP BY t.id;"
"SELECT t.id FROM cms11_f_topics t JOIN cms11_f_posts p ON p.id=(SELECT MIN(p.id) FROM cms11_f_posts p WHERE t.id=p.p_topic_id);"
In this I am explicitly saying which of multiple rows to join to (the one with the lowest ID).
IN
EXISTS
() subqueries
Joins selecting on a unique ID found via a minimiser/maximiser check
GROUP BY
DISTINCT * & COUNT(DISTINCT *)
Which one to use really depends on the situation.
The good news is some of the work towards #3354 was done in the gallery refactoring (as images and videos needed to be queried together, so it made sense to create an API for that, which will also work as an API for querying all content types at once).