Fixing #3 highlighted an issue in the way that the front page is coded, specifically with the complex way it attempts to eager-load records (see #2). It attempts to use a GROUP clause to return only a single Revision record from the join from the Pokemon model. However, this violates the SQL standard and is only allowed because a specific flag is used on the canonical server to allow it. Even with this, it does not achieve the intended result, and the record that is return from the GROUP is arbitrarily. This caused the correct record to be chosen in testing, and the incorrect record to be chosen in production. Commit 173effd7a9b847d156a5548e29ae7df67798c7a2 was an unsuccessful attempt to fix this bug that did not actually affect the SQL violation. Commit 91eeaa33a436ba2233f1fe7509f7c104db1d4533 changed from using a GROUP clause to using a DISTINCT in the SELECT clause, but this actually violates the same standard.
Fixing #3 highlighted an issue in the way that the front page is coded, specifically with the complex way it attempts to eager-load records (see #2). It attempts to use a GROUP clause to return only a single Revision record from the join from the Pokemon model. However, this violates the SQL standard and is only allowed because a specific flag is used on the canonical server to allow it. Even with this, it does not achieve the intended result, and the record that is return from the GROUP is arbitrarily. This caused the correct record to be chosen in testing, and the incorrect record to be chosen in production. Commit 173effd7a9b847d156a5548e29ae7df67798c7a2 was an unsuccessful attempt to fix this bug that did not actually affect the SQL violation. Commit 91eeaa33a436ba2233f1fe7509f7c104db1d4533 changed from using a GROUP clause to using a DISTINCT in the SELECT clause, but this actually violates the same standard.