I''m not convinced that http://github.com/rails/rails/commit/feed7b4cfd860bdc9f5b4efc2ca2af76cb01d55d (simply replacing the postgres gem with the pg gem in the CI server setup instructions) is the right resolution. We had a mystery build break yesterday which pointed to the PostgreSQL AR tests; rebuilding immediately made the break go away, and the commit didn''t touch AR at all, so I reluctantly (very reluctantly) say "gremlins." The problem with this fix, though, is that the AR driver for PostgreSQL has code to detect which of the two gems is installed, and to take different code - and test - paths depending on which one is there. We''ve had failures in the past (http://rails.lighthouseapp.com/projects/8994/tickets/1748 ) that amounted to support of one or the other being broken. Unfortunately, in the absence of any clear decision on which way to go, the code is still trying to support both. By having only one or the other on the CI server, we''re only testing some of the PG code - and we have within the past several months seen breaks that affects pg but not postgres AND breaks that affected postgres but not pg. One possible resolution would be for us to have both gems available on the CI server, and to increase the sophistication of the build script to run the AR tests using each one in isolation - I know Chad Woolley was looking into this. Another would be for us to declare the older postgres gem as unsupported, and to just accept any breaks that happen with it - that''s sort of what this swap in the CI setup does, but without making any particular note of it. But I''m rather leery of having code paths in AR that don''t get tested, especially given that we''ve seen bugs in those code paths recently. Mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Jan 29, 2009 at 5:09 AM, Mike Gunderloy <larkware@gmail.com> wrote:> One possible resolution would be for us to have both gems available on > the CI server, and to increase the sophistication of the build script > to run the AR tests using each one in isolation - I know Chad Woolley > was looking into this. Another would be for us to declare the older > postgres gem as unsupported, and to just accept any breaks that happen > with it - that''s sort of what this swap in the CI setup does, but > without making any particular note of it. But I''m rather leery of > having code paths in AR that don''t get tested, especially given that > we''ve seen bugs in those code paths recently.Koz and I discussed this on IRC. I think his plan was to send an email to this list indicating plans to deprecate the postgres gem in a future version. You just beat him to it :) The current state is that geminstaller.yml only contains the pg gem, which imples that is the ''official'' one, even though the code which falls back to postgres gem hasn''t been removed yet. I agree that there should be more sophistication to test other areas (are there others?) which do this "fallback" alternate gem activation approach - untested code paths are bad. Most of the work here will be in the rake test tasks, to ensure that the proper one is activated (via a flag, param, etc), then ci_build.rb can have multiple steps to test both scenarios. -- Chad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
> Koz and I discussed this on IRC. I think his plan was to send an > email to this list indicating plans to deprecate the postgres gem in a > future version. You just beat him to it :)Indeed, this was basically the email I intended to send :)> The current state is that > geminstaller.yml only contains the pg gem, which imples that is the > ''official'' one, even though the code which falls back to postgres gem > hasn''t been removed yet. > > I agree that there should be more sophistication to test other areas > (are there others?) which do this "fallback" alternate gem activation > approach - untested code paths are bad. Most of the work here will be > in the rake test tasks, to ensure that the proper one is activated > (via a flag, param, etc), then ci_build.rb can have multiple steps to > test both scenarios.It will also need some changes to the adapter to make sure that it behaves consistently when you only have pg installed and run the tests with postgres (or vice versa). But fundamentally, I''m hoping some postgresql users can shed some light on the situation. There are two postgres gems, we''ll support both for 2.3, but do we need to do that for 3.0? Are there any situations where you can''t just install pg? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---