Defaulting boolean attributes to true about rails-style-guide

[garethrees]

Personally when it comes to booleans I add defaults in the migration to the table itself.

[slamotte]

As with @garethrees, I set boolean defaults in the table's migration.

[garyv]

To play devil's advocate for a moment, I just read a blog post suggesting that anytime you store a Boolean in a database, it's a code smell, and you should use a State Machine pattern instead, because it it's easier to maintain or something.

http://railstips.org/blog/archives/2012/10/10/booleans-are-baaaaaaaaaad/

Personally, I've never found State Machines to be intuitive, and I didn't find this argument very convincing. A Boolean state is a much simpler and easier concept to work with. But it's an interesting idea, and it would sidestep the need to set defaults in the database.

[slamotte]

@garyv thanks for that link. I get what you were trying to add. Personally I hated the article's title (too absolute and polarizing) as well as his example (too contrived, and as you would read in the comments, his problem was really due to a poor design and naming) but regardless, it's an alternative.

I see nothing wrong with using booleans in a table but that's probably because I've been coding long enough to inherently recognize when to use them versus something else. See http://goo.gl/SD8J7

[bbatsov]

Well, setting the defaults in the migrations might be a better idea (especially if several applications are accessing the database).

[slamotte]

@bbatsov I know it's not "The Rails Way" but I'm a big fan of putting such things as defaults, unique indexes, and declarative referential integrity constraints into databases. If there's the slightest possibility that another app might ever touch the database then I consider this imperative. I've had many heated debates about how this isn't portable or designed right but in my professional opinion you've got to protect your data.

[pirj]

I believe this was addressed in #275