#1316 confirmed
Jonathan Stott (namelessjon)

:unique and :unique_index merge causes some inconsistencies

Reported by Jonathan Stott (namelessjon) | June 11th, 2010 @ 08:18 AM | in 1.1.1

For a more complete look, see:


To summarize briefly:

If the :unique option is used on more than one properties, the unique indicies created in the database and the validations created are either

  1. Inconsistent with each other
  2. Result in redundant queries being issued and/or redundant indicies being created

Comments and changes to this ticket

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 12th, 2010 @ 12:57 AM

    @namelessjon: I'm going to have to look at this in more detail, but I should note that the value for :unique has nothing to do with he property names. It's the name of the unique index you want the property to belong to.

  • Jonathan Stott (namelessjon)

    Jonathan Stott (namelessjon) June 12th, 2010 @ 04:02 AM

    I agree that that would preserve the meaning of the old :unique_index behaviour that I was using in 0.10.2. Never the less, that's not how dm-validations treats it. In dm-validations, it is used as the scope of the uniqueness validator.

  • Martin Gamsjaeger (snusnu)

    Martin Gamsjaeger (snusnu) July 29th, 2010 @ 11:42 AM

    • State changed from “unconfirmed” to “confirmed”
    • Milestone set to 1.0.2
    • Milestone order changed from “0” to “0”

    fwiw, here's a standalone, demonstrating an issue i have with :unique on more than 1 property: http://pastie.org/1065704.txt

  • Dan Kubb (dkubb)
  • Dan Kubb (dkubb)
  • Xavier Shay

    Xavier Shay November 27th, 2010 @ 12:46 AM

    • Assigned user set to “Xavier Shay”

    I am investigating

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) December 2nd, 2010 @ 11:11 PM

    (from [52373a9b387aeb298384f501bd8c6369fdd8b7e4]) Uniqueness auto-validations now raise a helpful error message when you try to scope by an arbitrarily named group, rather than an actual

    It would be nice if this behaviour Just Worked, but I'm not confident on
    the interaction or intention between :unique and :unique_index, so for
    now this is strictly better than what was there.

    [#1316 state:confirmed] https://github.com/datamapper/dm-validations/commit/52373a9b387aeb2...

  • Xavier Shay

    Xavier Shay December 2nd, 2010 @ 11:14 PM

    • Assigned user cleared.

    So that commit is a bit of a cop out but it's what I've got at the moment.
    I can't quite wrap my head around why we need both :unique and :unique_index.
    Would appreciate others chiming in as to what needs to happen to be able to mark this ticket as resolved.

    Removing assignment from myself because I'm not in a position to push this forwards.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) March 16th, 2011 @ 10:41 PM

    • Milestone changed from 1.1 to 1.1.1
    • Milestone order changed from “1” to “0”
  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) March 23rd, 2011 @ 11:09 PM

    What I'd like to see is :unique_index deprecated, and :unique used across the board.

    The allows values for :unique should be one of:

    • A Boolean
    • A Symbol
    • An Array of Symbols

    A Boolean should be a uniqueness constraint containing just the property. The name of the constraint is generated by the system.

    A Symbol should be a uniqueness constraint containing all the properties that share the Symbol. The Symbol is used for the name.

    An Array of Symbols behaves the same way as a single Symbol, only it defines multiple constrains the property belongs to.

    These constraints have no direct side effects. Other plugins can reflect on the data to provide special behaviour, but it's just for informational purposes as far as dm-core is concerned.

    I would like for dm-validations and dm-migrations to be in sync. That is, the database level constraint should never be triggered when a record is validated before saving; except in the case where there is a race condition between the check and the save -- whether this is common or rare is different for each environment; in my case I have rarely seen it.

  • Xavier Shay

    Xavier Shay March 23rd, 2011 @ 11:12 PM

    • Assigned user set to “Xavier Shay”

    Sounds good. I'll tackle this again.

  • Xavier Shay

    Xavier Shay March 30th, 2011 @ 04:18 AM

    • Assigned user cleared.

    Bowing out sorry, I've overcommitted myself.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Referenced by