On Fri, Feb 17, 2012 at 09:00:15AM -0800, kkeiter(a)redhat.com wrote: > From: Kenneth Keiter <ken(a)kenkeiter.com&gt; > > --- > src/app/models/pool.rb | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/app/models/pool.rb b/src/app/models/pool.rb > index 8529a9d..5d79cf3 100644 > --- a/src/app/models/pool.rb > +++ b/src/app/models/pool.rb > @@ -51,7 +51,7 @@ class Pool < ActiveRecord::Base > validates_presence_of :quota > validates_presence_of :pool_family > validates_inclusion_of :enabled, :in => [true, false] > - validates_uniqueness_of :name > + validates_uniqueness_of :name, :case_sensitive => false > validates_uniqueness_of :exported_as, :if => :exported_as > validates_length_of :name, :maximum => 255 > > -- > 1.7.4.1 This causes a test failure: cucumber features/catalogs.feature:10 # Scenario: Create a new catalog It's actually a problem with pool_steps.rb, where we look up a pool named 'default' and create it if it's not failed. find_by_name is case-sensitive (on Postgres), so we find no pool with that name and thus create one -- but then the validation fails because "Default" exists. I think the right thing to do is to fix the test to just use 'Default', as opposed to doing a case-insensitive lookup. The problem I realized with case-insensitivity, by the way, is that the LOWER() operation ruins our ability to use an index -- so calling it forces a table scan[1]. That's (arguably) not a big deal when creating a new pool, which should happen relatively infrequently and which shouldn't be searching through tens of thousands of rows... But I'd hate to try to hack the find to be case-insensitive. So changing the test seems to be the least-bad option. I'm going to change the test (and search for any other happenings of this) and send that as a follow-up. -- Matt [1] http://techblog.floorplanner.com/2009/11/17/case-insensitive-validates_un...