ValidatesUniqueness with Scoping doesn't play with "type" (and probably other magic field names.

Scoping to :type means you call the type method on the record, which returns its class.

Should we call read_attribute(:type) instead? What about folks who want to scope to a method which has no corresponding attribute, then?

A workaround:

def ruby_type() read_attribute('type') end
validates_uniqueness_of :target_id, :scope => [:ruby_type, :source_id]

Replying to rubyonrails@datanomisch.de:

On windows XP professional with:
InstantRails 1.4
Ruby 1.8.5
RoR 1.1.6

I encountered the same problem, and reduced it to a minimal case before I found this bug entry. For testing, I created a new rails project using a MySQL database with single (real) table, and 2 models. The table only has 3 fields; id, name, type. I did not even bother creating a controller. Below is the initial mimimal failing sample, followed by a variation to attempt to get past the error, PLUS a different work around.

First failing case

schema.rb

ActiveRecord::Schema.define(:version => 1) do
  create_table "parents", :force => true do |t|
    t.column "name", :string
    t.column "type", :string
  end
end

parent.rb

class Parent < ActiveRecord::Base
  validates_uniqueness_of :name, :scope => :type
end

child.rb

class Child < Parent
end

parent_test.rb

require File.dirname(__FILE__) + '/../test_helper'

class ParentTest < Test::Unit::TestCase
  fixtures :parents

  def test_sti
    assert Child.new( :name => "Peter" ).valid?, "fatal"
  end
end

The test run

C:\InstantRails\InstantRails-1.4-win\rails_apps\sti>ruby test/unit/parent_test.rb
Loaded suite test/unit/parent_test
Started
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:531: warning: Object#type is deprecated; use Object#class
E
Finished in 0.328 seconds.

  1) Error:
test_sti(ParentTest):
TypeError: can't dump anonymous class Class
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/1.8/yaml/rubytypes.rb:6:in `to_yaml'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/abstract/quoting.rb:22:in `quote'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/mysql_adapter.rb:122:in `quote'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1305:in `quote_bound_value'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1287:in `replace_bind_variables'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1287:in `gsub'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1287:in `replace_bind_variables'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1276:in `sanitize_sql'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1062:in `add_conditions!'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:1012:in `construct_finder_sql'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:924:in `find_every'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:918:in `find_initial'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/base.rb:380:in `find'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:540:in `validates_uniqueness_of'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:302:in `validates_each'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:299:in `each'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:299:in `validates_each'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:806:in `call'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:806:in `run_validations'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:800:in `each'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:800:in `run_validations'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:764:in `valid_without_callbacks'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/callbacks.rb:310:in `valid?'
test/unit/parent_test.rb:7:in `test_sti'

The very start of the error messages above showed a warning about a deprecated Object:type reference. I tried just changing the :scope => :type to :scope => :class, but that failed in (almost) the same way. The trace shows all of the same modules and line numbers, but the deprecated warning went away.

Second failing case

parent.rb

class Parent < ActiveRecord::Base
  validates_uniqueness_of :name, :scope => :class
end

The test run

    C:\InstantRails\InstantRails-1.4-win\rails_apps\sti>ruby test/unit/parent_test.rb
Loaded suite test/unit/parent_test
Started
E
Finished in 0.734 seconds.

  1) Error:
test_sti(ParentTest):
TypeError: can't dump anonymous class Class
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/1.8/yaml/rubytypes.rb:6:in `to_yaml'
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/abstract/quoting.rb:22:in `quote'
. . .
C:/InstantRails/InstantRails-1.4-win/ruby/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/callbacks.rb:310:in `valid?'
test/unit/parent_test.rb:7:in `test_sti'

Here is (one way) to get this work, as long as you can change the type field in the database to something else. I used class_name then override the inheritance_column to point to the alternate name, and no more complaints. I expect that one of those each or every references in the traceback is getting the field names (database columns), and building an 'executable' .<field> (.type here) reference from it. The complete fix might be as simple as changing that to a [:<field>] reference. Would that impact other fields or performance?

Working adjustment (workaround)

parent.rb

class Parent < ActiveRecord::Base
  validates_uniqueness_of :name, :scope => :class_name
  def self.inheritance_column() :class_name end
end

schema.rb

ActiveRecord::Schema.define(:version => 1) do
  create_table "parents", :force => true do |t|
    t.column "name", :string
    t.column "class_name", :string
  end
end

The test run

C:\InstantRails\InstantRails-1.4-win\rails_apps\sti>ruby test/unit/parent_test.b
Loaded suite test/unit/parent_test
Started
.
Finished in 0.281 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

Replying to mmerlin:

I tried to make the :scope reference generic, so that it would not be dependent on the specific inheritance column name. Rails does not like anything I tried.

self.inheritance_column() :class_name end

valididates_uniqueness_of ... :scope => :class_name #WORKS
valididates_uniqueness_of ... :scope => :class #FAILS
valididates_uniqueness_of ... :scope => inheritance_column #FAILS

mmerlin, did you see the workaround I proposed?

Simply create a method that reads the inheritance column, and scope on that method.

We have three choices in this scenario: 1. change the inheritance column name in the database 2. create a method that returns the value of the inheritance column and scope on that 3. change uniqueness scoping to read the given *attribute* rather than call the given method

I think the fact that (2) is a very simple workaround for this pathological scenario is reason enough to leave the implementation as-is.

Replying to bitsweat:

mmerlin, did you see the workaround I proposed? Simply create a method that reads the inheritance column, and scope on that method. We have three choices in this scenario: 1. change the inheritance column name in the database 2. create a method that returns the value of the inheritance column and scope on that 3. change uniqueness scoping to read the given *attribute* rather than call the given method I think the fact that (2) is a very simple workaround for this pathological scenario is reason enough to leave the implementation as-is.

I saw the workaround, but to (noob) me, option 1 looked cleaner [at least with a new project / database]. It did get rid of the initial error, but I have been trying to 'enhance' it to learn more about how RoR works. Just found one more problem with my implementation of option 1. I had:

def self.inheritance_column() :class_name end

It turns out that Rails does not 'see' that as a real inheritance column. When doing Child.new(), the class_name was being left blank / nil. Changing that to:

def self.inheritance_column() "class_name" end

and it is being populated properly again.

Option 2 is also viable (although I did not test that case [yet]). Rails is still 'broken', because using :scope => :class or :scope => :type should either work, or be documented as invalid, with the [preferred] alternative. That dump / trace is a bit extreme for using what appears perfectly reasonable, especially since the error only occurs [for me at least] when doing .valid?, with nothing pointing to what the real problem is [at least when using :scope => :class]

Recommended fix by bitsweat does not work. Thus, I'm reopening.

If you scope on :ruby_type where ruby_type is a method you've defined in the model, this simply causes the database query for the "ruby_type" column to fail. Remember, the scoping is done at a database level -- it's not loading every database row into a n ActiveRecord object just to compare their type.

mmerlin's workaround of using a different name for the inheritance column does work, but changing the default name of the inheritance column just to get unique scoping seems a bit unreasonable.

I would say changing the line in validates_each from: [code]value = record.send(attr)/code to [code]value = record.attributes[attr.to_s]/code would be the best fix.

Since the validates is based on SQL anyway, I can't imagine there would be many scenarios where it is going to fail?

The other possibilities I see would be:

1. Letting us choose between whether it should use .send (which would be default), or .attributes.
2. Letting the user specify a different name for the database column to how the value for that column is found (.send(:ruby_type), and 'type' column in the database

This may not be a great idea but I've found that redefining type works as a workaround. I haven't seen any ill effects of doing this so far. Ruby always emits a warning when you call type so it's unlikely that Rails calls it anywhere intentionally.

  def type
    read_attribute(:type)
  end