Connection adapter's limit and automatic validations

Gary_Weaver · December 18, 2012, 10:58pm

to field to store actual limit for that type?

At first it may seem like you could just look at NATIVE_DATABASE_TYPES in the adapter to get the type, e.g.:

rails/rails/blob/3-2-stable/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb#L220


      
            end
          
          
  def tsvector(*args)
              options = args.extract_options!
              column(args[0], 'tsvector', options)
            end
          end
          
          
ADAPTER_NAME = 'PostgreSQL'
          
          
NATIVE_DATABASE_TYPES = {
            :primary_key => "serial primary key",
            :string      => { :name => "character varying", :limit => 255 },
            :text        => { :name => "text" },
            :integer     => { :name => "integer" },
            :float       => { :name => "float" },
            :decimal     => { :name => "decimal" },
            :datetime    => { :name => "timestamp" },
            :timestamp   => { :name => "timestamp" },
            :time        => { :name => "time" },
            :date        => { :name => "date" },

and then based on what you know about the type of the database, maybe you could assume limits, but that may vary between versions of the database.

But, there is no single limit or associated database type for an associated Ruby/Rails type in ActiveRecord- other than the limit of the object itself in Ruby which could even be less than the associated database type. You may have a legacy schema, then maybe you’re using structure.sql, or executing custom SQL in migrations to create tables with other types. You can also use something like the activerecord-native_db_types_override gem that alters what types are used in migrations: https://github.com/garysweaver/activerecord-native_db_types_override (not suggesting to use that unless you need to, though)

If you changed types using that gem between migrations, then depending on when you ran the migration, the type that was created may be different. All kinds of fun. You can’t guarantee a simple type → database type mapping will be in effect.

So, I think t would need to be an attribute-level, not migration level, definition, I think. And ,with Rails/ActiveRecord, you don’t have to define the attributes in the model, they are just there. Therefore, adding additional code that defines limits would make the most sense to just put in validations in the model, since that is where that sort of thing tends to go.

Now that we are back at square one, let’s discuss options. You could define these validations yourself, or as you said you could use something like valle, but if you use something that is dynamically creating the validation, that is going to be less efficient than it would be to have them already coded in the model. To make it both efficient and automate the process of autogenerating the validations, you’d want to alter the Rails generators.

You could make an option that you could pass into the Rails generator for models that would look at something similar to NATIVE_DATABASE_TYPES in the adapter, but instead of just types, it would define the limits and other validation information that the generator would need to create an appropriate validation, and then it would create the validation(s) in the model code that it generated.

But, this would add to the amount of maintenance required on the adapter and generator code in Rails significantly, so I doubt that the core team would be interested. They have enough to do.

So instead, you might want to override the Rails generators and hardcode and maintain the type to limit mapping in your own gem instead. If you did that then when people were starting new Rails projects, they might like to use your gem so they could have nice validation messages without much work, and it could be a nice alternative to valle and validates_lengths_from_database.

Hope that helps, Gary