Closed (fixed)
Project:
JSON:API
Version:
8.x-2.x-dev
Component:
Code
Priority:
Critical
Category:
Task
Assigned:
Issue tags:
Reporter:
Created:
22 Jan 2019 at 17:23 UTC
Updated:
6 Feb 2019 at 17:09 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
wim leersThat means we'd run into this problem in the future even without Postgres. Core is keeping us honest :)
+1
+1
Comment #3
gabesulliceUpdate: syntax errors mask the expected failures. To save you clicks... MySQL 8 failed
UserTestand Postgres failed many.The first patch changes nothing, it just gives us something to prove the "bug" with MySQL 8 and Postgres.
The second commit is the simplest change. It might break some tests.
Comment #4
e0ipso#1 incurs into a performance penalty, so -1 for me. I like #3 over others.
Tests assert that sorting works. Unsorted defaults to DB implementation (not on us to test). We only need to test that an unsorted collection works. That could be a dedicated test.
Comment #5
gabesulliceI really wonder what the impact of ordering by an integer primary key really has, but I also admit that #1 being the easiest to implement was a major factor in my decision (which is a polite way of saying, "my laziness affects my decision-making").
Here's an attempt at option 3. I think this will solve for MySQL 8, but it might not address all the PostgreSQL errors yet.
Update: that's frustrating, I'm running MySQL 8 locally and do not get the same errors with
UserTest.Comment #6
wim leersI hadn't thought about that. This is an excellent point. 👏 🙏
@e0ipso convinced me we want #2 or #3.
Comment #7
gabesulliceI think this should fix MySQL 8. On the bright side, #5 did better on Postgres than I expected :)
Comment #8
gabesulliceComment #9
gabesulliceI was a little baffled by this one on PostgreSQL:
Since it's asserting a collection count, not an ID or something. I realized that it's because an unpublished node was appearing on a different page than expected because of a different ordering. RuntimeAccessChecks--
Comment #10
gabesulliceComment #11
wim leersSo the patch is green for #3. @e0ipso expressed his preference for this approach. Great!
I have just one concern: we're now coupling many of our tests to sorting. On the one hand this is completely reasonable, on the other hand it means there is a very slight risk in that we're no longer testing the absence of sorts. However …
Gabe already thought about that :)
Given that, I'm RTBC'ing this, but not yet committing: I'd like @e0ipso to explicitly +1 this too.
Comment #12
wim leersComment #13
e0ipso+1
Comment #15
wim leers🎉