It is a good point you touch there, Matt. Maybe the use of presence is not
recommended for boolean columns, and the recommended practice is to set a
default, thereby ensuring that there will be only trues and falses...
On Thu, Nov 14, 2013 at 1:57 PM, Matt Jones wrote:
>
> On Nov 14, 2013, at 8
On Nov 14, 2013, at 8:14 AM, Sergio Campamá wrote:
> Last night a friend of mine started ranting about validates_presence_of
> :boolean_field returning not valid when the boolean field is false.
>
> I checked the rails issues and this seems to be a pretty common concern about
> the naming of
Sergio,
When I was starting with Rails, I felt a similar dissonance about the
presence validator, but as you say, it's important to think of validations
in the context of Rails. After all, an empty string is not NULL in the
database but would also fail the presence validator. As Rafael said, the
o
Yes, I get what you mean Rafael.
I think the main misconception is that in the database sense, a value of
'false' is indeed present, and the only way for that field to be NOT
present would be for it to be NULL, again in the database.
Now, in the application context, it is commonly believed that a
I agree with Rafael.
Using "boolean" in the macro name is also a smell for me. In Ruby all
objects are booleans. Ruby has no Boolean class, there is no hierarchy for
booleans, the boolean space is flat (confirmed by matz here
https://www.ruby-forum.com/topic/4412411#1103364). Thus, while I know wh
This will cause more misconceptions yet.
validate_presence_of :something
Means to me
something.prensent?
And
false.present? # => false
So even we call presence_of_boolean we still using the word presence that
means that I should expect to Rails call present?
validates_inclusion is not “hacky
Last night a friend of mine started ranting about validates_presence_of
:boolean_field returning not valid when the boolean field is false.
I checked the rails issues and this seems to be a pretty common concern
about the naming of 'presence' .
Instead of changing the behaviour of the presence v
AFAICT, it's not possible to force this currently.
Frequently the application trace is inadequate and you need the full trace
to get to the bottom of the problem. For example, let's say your layout
template calls non application (3rd party gem) code which raises. The
application trace will co
