Hi guys, There are quite a number of people blocked from upgrading to 2.3 because of #2189, whereby (it is thought due to http://github.com/rails/rails/commit/6543426c73fa9ccf3649d7cbacbbb0fda9b6a099) 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. -- Cheers Koz
On Mon, Jun 1, 2009 at 1:37 PM, Michael Koziarski <michael@koziarski.com> wrote:> 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.
On Mon, Jun 1, 2009 at 1:41 PM, Will Bryant <will.bryant@gmail.com> wrote:> > On Mon, Jun 1, 2009 at 1:37 PM, Michael Koziarski <michael@koziarski.com> wrote: >> 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.> > >-- Cheers Koz