Hi guys,
There are quite a number of people blocked from upgrading to 2.3
because of #2189, whereby (it is thought due to
Ensure calculations respect scoped :select [#1334 state:resolved] · rails/rails@6543426 · GitHub)
count queries are broken on mysql. This is a regression that happened
post the original 2.3 RC.
We really need to try and get this fixed for the next patch release,
but there's a bunch of different solutions being proposed and slow
progress being made on the discussion on the ticket, so I thought I'd
open it up here.
Basically, the options are:
1. Revert the patch that introduced the regression - it wasn't
properly +1d in the first place
2. Use a regex to replace the count term originating from the
association's :select, turning it back into COUNT(*)
3. Use a regex to replace the count term originating from the
association's :select, turning it into COUNT(tablename.primary_key)
I personally favor the last because I think that's what we'll want to
be using everywhere long term, but there are reasonable arguments for
the other two also.
Thoughts?
Will
Basically, the options are:
1. Revert the patch that introduced the regression - it wasn't
properly +1d in the first place
2. Use a regex to replace the count term originating from the
association's :select, turning it back into COUNT(*)
3. Use a regex to replace the count term originating from the
association's :select, turning it into COUNT(tablename.primary_key)
I personally favor the last because I think that's what we'll want to
be using everywhere long term, but there are reasonable arguments for
the other two also.
Thoughts?
Part of me can't go past:
Some people, when confronted with a problem, think “I know, I'll use
regular expressions.” Now they have two problems.
I'm pretty much in favour of #1 for 2-3-stable and investigating 2 or
3 for master. Barring any objections I'll revert it today and we can
keep tinkering in master. Now my month of conference travel is almost
over I'm pretty keen to focus on getting a point release out.
Sounds good to me.
If we're going to work on a new solution for master, this would be a
good time to consider suggestions like COUNT(DISTINCT
`tablename`.primary_key) to deal with joins etc. too.
I'm pretty much in favour of #1 for 2-3-stable and investigating 2 or
3 for master. Barring any objections I'll revert it today and we can
keep tinkering in master. Now my month of conference travel is almost
over I'm pretty keen to focus on getting a point release out.
Sounds good to me.
Done. I've also added the failing tests in the ticket to 2-3-stable
so we should catch this if the change accidentally comes back.
If we're going to work on a new solution for master, this would be a
good time to consider suggestions like COUNT(DISTINCT
`tablename`.primary_key) to deal with joins etc. too.
Sounds good to me.
