Boolean model.column? == true even if value is 0

I had a working 1.2 app which I have just updated to 2.3.2 – mostly
seems good so far, but the Rails technique for booleans is acting up.

MySQL column = childSensitiveCase varchar(1) NOT NULL default ‘0’

If I use a simple debug() output, I get this:

debug(@child.isSensitiveCase) # --> “0”
debug(@child.isSensitiveCase?) # --> true

change the value in the db to 1

debug(@child.isSensitiveCase) # --> “1”
debug(@child.isSensitiveCase?) # --> true

change the value in the db to F or f and it is still resolving to true.

The code worked just fine in 1.2

Has something else changed since 1.2 in handling booleans?

– gw

On Jul 27, 5:45 pm, Greg W. [email protected]
wrote:

I had a working 1.2 app which I have just updated to 2.3.2 – mostly
seems good so far, but the Rails technique for booleans is acting up.

MySQL column = childSensitiveCase varchar(1) NOT NULL default ‘0’

as long as I remember, with mysql rails expects booleans to be tinyint
columns

Fred

For those that are interested, … the discussion in the AWDR book
that preceded that particular quote and the suggested action for
dealing with differences in underlying db storage of boolean vals:

DON’T DO THIS


if user.supervisor

INSTEAD, DO THIS


if user.supervisor?

Jeff

On Jul 27, 3:41 pm, Greg W. [email protected]

On Mon, Jul 27, 2009 at 5:06 PM, Jeff L. [email protected]
wrote:

On Jul 27, 5:45 pm, Greg W. [email protected]
AWDWR 3rd Ed pg 320:

Greg, if you’re referencing AWDwR 3ed, then you must have read the
section
17.1 which explains the mappings between Ruby symbols and the underlying
database in regards to migrations.

-Conrad

Frederick C. wrote:

On Jul 27, 5:45�pm, Greg W. [email protected]
wrote:

I had a working 1.2 app which I have just updated to 2.3.2 – mostly
seems good so far, but the Rails technique for booleans is acting up.
MySQL column = childSensitiveCase varchar(1) NOT NULL default ‘0’

as long as I remember, with mysql rails expects booleans to be tinyint
columns

Well, like I say this is currently working on an instance running as
Rails 1.2, and…

AWDWR 3rd Ed pg 320:

 "This form of attribute accessor looks at the column’s value. It is 

interpreted as false only if it is the number 0; one of the strings “0”,
“f”, “false”, or “” (the empty string); a nil; or the constant false.
Otherwise, it is interpreted as true."

To me this implies a varchar field will work.

However, I changed the column to tinyint(1) and that does indeed behave
as desired. So, I’ll just change it. Thx.

– gw

Conrad T. wrote:

On Mon, Jul 27, 2009 at 5:06 PM, Jeff L. [email protected]
wrote:

On Jul 27, 5:45 pm, Greg W. [email protected]
AWDWR 3rd Ed pg 320:

Greg, if you’re referencing AWDwR 3ed, then you must have read the
section
17.1 which explains the mappings between Ruby symbols and the underlying
database in regards to migrations.

Sure, but… (to clarify how I drew my conclusions)

That describes what a migration will create–which could be independent
of how the accessor works. IOW, it doesn’t necessarily imply that
tinyint(1) is the only valid field type on which the ? accessor will
work. In fact, that’s exactly what I am saying, the rest of the text in
the book which covers this topic specifically implies that a character
field will work.

The entire quote:


To query a column as a boolean value in a condition, we must append a
ques-
tion mark to the column’s name:

INSTEAD, DO THIS

user = Users.find_by_name(“Dave”)
if user.superuser?
grant_privileges
end

This form of attribute accessor looks at the column’s value. It is
interpreted as
false only if it is the number 0; one of the strings “0”, “f”, “false”,
or “” (the empty
string); a nil; or the constant false. Otherwise, it is interpreted as
true.

This happens to be the exact same text from the 2nd Edition, and this
behavior is true for 1.2 – a MySQL varchar(1) does behave with the
expected true/false results with string values in the column as the text
above describes. But for 2.3 it must be a tinyint(1) and obviously only
the 0 and 1 values are usable.

Anyway, not a big deal. I changed the field type, and I added an Errata
to the pragprog web site for the book.

– gw

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs