Rails core - Dec 2012 - Connection adapter's limit and automatic validations

The intro to this topic: https://github.com/kaize/valle. This problem is 
not new. There are some similar gems, e.g. 
http://github.com/rubiety/validates_lengths_from_database. All, in general, 
do the same thing - get information about the limitations (length or 
maximum/minimum value) and apply them to the model.

At this moment, limit is only used for mapping between ActiveRecord and 
database. For example (suppose we have PostgreSQL DB):

migration with
    t.integer :age, limit: 2
transforms into `age smallint` in PostgreSQL.


But, default integer field do not have limit:

migration with
    t.integer :age
transforms into `age integer` in PostgreSQL. 


PostgreSQL actually can store only 4 bytes.

This means: "*limit inside AbstractAdapter::Column does not mean the actual
limit in the database for that type*"

I would like to ask does it make sense (to Rails):
1) to field to store actual limit for that type?
2) to implement an automatic check if value is out of acceptable range?

Regards,
Anton

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/qxaWMMTLxmsJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

I don''t think this make sense to be in Rails.

We don''t want to burden the user by default with a lot of validations.

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca



On Tue, Dec 18, 2012 at 9:08 AM, akalyaev <anton.kalyaev@gmail.com> wrote:
> The intro to this topic: https://github.com/kaize/valle. This problem is
> not new. There are some similar gems, e.g.
> http://github.com/rubiety/validates_lengths_from_database. All, in
> general, do the same thing - get information about the limitations (length
> or maximum/minimum value) and apply them to the model.
>
> At this moment, limit is only used for mapping between ActiveRecord and
> database. For example (suppose we have PostgreSQL DB):
>
> migration with
>     t.integer :age, limit: 2
> transforms into `age smallint` in PostgreSQL.
>
>
> But, default integer field do not have limit:
>
> migration with
>     t.integer :age
> transforms into `age integer` in PostgreSQL.
>
>
> PostgreSQL actually can store only 4 bytes.
>
> This means: "*limit inside AbstractAdapter::Column does not mean the
> actual limit in the database for that type*"
>
> I would like to ask does it make sense (to Rails):
> 1) to field to store actual limit for that type?
> 2) to implement an automatic check if value is out of acceptable range?
>
> Regards,
> Anton
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rubyonrails-core/-/qxaWMMTLxmsJ.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

1) 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.:
https://github.com/rails/rails/blob/3-2-stable/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb#L220
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

On Tuesday, December 18, 2012 7:08:07 AM UTC-5, akalyaev
wrote:
>
> The intro to this topic: https://github.com/kaize/valle. This problem is 
> not new. There are some similar gems, e.g. 
> http://github.com/rubiety/validates_lengths_from_database. All, in 
> general, do the same thing - get information about the limitations (length 
> or maximum/minimum value) and apply them to the model.
>
> At this moment, limit is only used for mapping between ActiveRecord and 
> database. For example (suppose we have PostgreSQL DB):
>
> migration with
>     t.integer :age, limit: 2
> transforms into `age smallint` in PostgreSQL.
>
>
> But, default integer field do not have limit:
>
> migration with
>     t.integer :age
> transforms into `age integer` in PostgreSQL. 
>
>
> PostgreSQL actually can store only 4 bytes.
>
> This means: "*limit inside AbstractAdapter::Column does not mean the 
> actual limit in the database for that type*"
>
> I would like to ask does it make sense (to Rails):
> 1) to field to store actual limit for that type?
> 2) to implement an automatic check if value is out of acceptable range?
>
> Regards,
> Anton
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/jPH3rMiJiPkJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.