On Tue, May 7, 2013 at 1:37 PM, Robert Walker <[email protected]> wrote: > Fritz Anderson wrote in post #1108098: >> ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.3.0] >> Rails 3.2.13 >> >> I have a validates ... :uniqueness constraint on one of the attributes >> of an ActiveRecord class. >> >> In my test suite, I set the attribute from the same attribute in a >> record in the fixture. I then send invalid? to the object under test. >> invalid? returns _false_, and the .errors object for the record shows no >> errors. >> >> A :uniqueness constraint on another attribute does invalidate the >> record. All validations on other attributes behave as expected. >> >> I've done what I could to search the Rails docs, Google, Stack Overflow, >> and this forum for similar problems, and found nothing. >> >> What's wrong? > > I didn't take the time to dig through your test code thoroughly, but > there are a few things you need to know about uniqueness validation on > ActiveRecord? The primary issue is that uniqueness is not guaranteed. > AFAIK there still exists a race condition that could cause duplicates to > be allowed in the database. This is especially true when there are > multiple instances of an app running. Or when records can be added > outside of the application. > > Again, AFAIK the ONLY way to guarantee uniqueness is by using a unique > index on the column at the database level. Validation login in an ORM > (like ActiveRecord IS NOT sufficient). It is convenient to have because > it's easier to recover from a uniqueness violation, but it does not > remove the necessity of having the unique constraint in the database. > > A basic explanation of this can be found here: > http://guides.rubyonrails.org/active_record_validations_callbacks.html#uniqueness > > I have a strong suspicion that your issue is related to this limitation. >
In addition to the race condition Robert mentions, is that under test, your database excursions might very well be wrapped in transactions and not yet committed to the database. I suggest watching the log and see if things are committed; unit tests generally should not rely on the database to perform as such. Testing these sorts of things is more an integration test where you are testing full paths back and forth. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
