#175 ✓resolved
Brian Rose

Auto_Validations should be handled in the order specified

Reported by Brian Rose | March 2nd, 2008 @ 10:32 PM

The current method of handling auto_validations! is specified via a hash, which causes out-of-order problems (i.e. specifying ':nullable => false, :format => :email_address' and validations happening backward). To fix this, we can introduce an array instead of a hash (see patch). While it isn't ideal, it works more reliably.

It's worth noting that hashes are ordered in Ruby 1.9, and this change can be rolled back once 1.9 is considered de facto.

Comments and changes to this ticket

  • Sam Smoot

    Sam Smoot March 15th, 2008 @ 06:42 PM

    • State changed from “new” to “open”

    I think a better solution to this issue might involve introducing the concept of validator precedence. Just like + takes higher precedence than /, we can make some assumptions about validations such as a validates_presence_of takes precedence over anything else.

    Poke holes please. ;-)

    I do think the internal mechanisms should account for declared order, it's the inlines I'm not so sure about since they're more than just validators. They can also be field definitions/constraints.

  • Dan Kubb (dkubb)
  • Sam Smoot

    Sam Smoot May 21st, 2008 @ 01:26 AM

    • Assigned user set to “Adam French”

    Adam,

    A feature for you to implement! :-)

    Validation precedence as auto-validations are concerned.

    Just to clarify: Standard validations should preserve the order in which they are defined. Auto-validations should provide a precedence to give the Hash options some more meaning.

    So the change here is that we need to map/select something like:

    [:nullable, :length, :format].each do |type|
      if options.has_key?(type)
        case type
        when :nullable then validates_is_present(name)
        when :length then validates_length(name, option[:length])
        else raise 'CAN BE AWESOMES!'
        end
      end
    end
    

    You get the point. Precedence for auto-validations only.

  • Sam Smoot
  • Adam French

    Adam French July 20th, 2008 @ 05:46 PM

    • Assigned user cleared.
    • Tag set to dm-more, patch, property
  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) December 12th, 2008 @ 03:25 PM

    • Tag changed from dm-more, patch, property to dm-more, property
    • State changed from “open” to “resolved”

    This patch does not cleanly apply to dm-core.

    It looks like dm-validations has been updated so that auto-validation proceeds in a predefined manner, and validations are executed in the order they are defined in.

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 »

People watching this ticket

Pages