Skip to content


Subversion checkout URL

You can clone with
Download ZIP


column.limit returning nil from pg adapter #758

rubythings opened this Issue · 5 comments

4 participants


I've run into a problem trying to upgrade to 2.0.1 running with a postgres database using the pg 0.12.0 adapter (though earlier versions have the same problem). I've tracked this down to the inputs/base/validations.rb file where we have

       def column_limit
          if column? && column.respond_to?(:limit)
            case column.type
            when :integer
              (2 ** (column.limit * 8)).to_s.length + 1

column.limit is returning null for integer values, and this is breaking formtastic. I've put a nasty hack in my copy to set a default (col = column.limit || 4). A better solution would be to address this inside the postgres adapter, but I'm reporting here in case others need a quick fix, or someone can come up with a better idea.


@rubythings is there any significance to the "4", or did you just pick that as a number that suited in your case? Let's assume that a nil limit is valid and could be returned by any DB adaptor (Mongo?), then I wonder if we can also do some work in Formtastic to make this better/safer.


In fact, do we even need to be calculating this limit? As far as I can see, the only use of column_limit is to choose a maxlength for a stringish input. However, maxlength is not a valid attribute for input[type=number], so maybe we should get rid of it?


@haines great point. NumberInput includes Stringish, which defines input_html_options, which calls limit in the maxlength attribute, which calls column_limit.

There seems to be a few places we can hook in and remove this maxlength attribute, but I think we need to extract the maxlength logic out of Stringish#input_html_options into something like Stringish#maxlength, which would allow NumberInput to redefine this as nil.



I had a bit more of a look through the HTML5 spec and the size attribute (which is also set in Stringish#input_html_options) is not allowed for these inputs either (there's a good table showing which inputs accept which attributes). So, semantically, I think numeric inputs have diverged from stringish ones enough to consider them separate entities, and it'd be best to refactor NumberInput and RangeInput to inherit from Numeric rather than Stringish.

I'll knock something up.

@haines haines was assigned
@yabawock yabawock closed this in ab27e75
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.