Skip to content

3-state boolean columns emphasis on NOT NULL constraint #363

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 17 additions & 4 deletions README.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -1167,19 +1167,32 @@ And you'll have to consider the fact that most non-trivial apps share a database

=== 3-state Boolean [[three-state-boolean]]

With SQL databases, if a boolean column is not given a default value, it will have three possible values: `true`, `false` and `NULL`.
With SQL databases, if a boolean column is nullable, it will have three possible values: `true`, `false` and `NULL`.
Boolean operators https://en.wikipedia.org/wiki/Three-valued_logic[work in unexpected ways] with `NULL`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This article is long and math heavy, is there perhaps a better reference?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found https://modern-sql.com/concept/three-valued-logic and the quite succinct PostgreSQL documentation https://www.postgresql.org/docs/current/functions-logical.html

I tend to favour the first one but I'm concerned about the link becoming broken


For example in SQL queries, `true AND NULL` is `NULL` (not false), `true AND NULL OR false` is `NULL` (not false). This can make SQL queries return unexpected results.

To avoid such situations, boolean columns should always have a default value and a `NOT NULL` constraint.
To avoid such situations, boolean columns should always have a `NOT NULL` constraint.

Note that when adding a boolean column to an existing table, a default value should be put in place. Otherwise the `NOT NULL` constraint will break for existing rows.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or it can be added without the constraint, backfilled, and have the constraint added afterwards.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True ! Though adding the default is safer because between the backfill and adding the constraint, new rows might be inserted

Would you like to see a small phrase about the "no constraint, backfill, constraint" procedure ?


[source,ruby]
----
# bad - boolean without a default value
# bad - boolean column on a new table without a `NOT NULL` constraint
create_table :users do |t|
t.boolean :active
end

# bad - adding a boolean column without a `NOT NULL` constraint or without a default value to an existing table
add_column :users, :active, :boolean
add_column :users, :active, :boolean, null: false

# good - boolean column with a `NOT NULL` constraint for new tables
create_table :users do |t|
t.boolean :active, null: false
end

# good - boolean with a default value (`false` or `true`) and with restricted `NULL`
# good - boolean column with a `NOT NULL` constraint, and a default value (`false` or `true`) for existing tables
add_column :users, :active, :boolean, default: true, null: false
add_column :users, :admin, :boolean, default: false, null: false
----
Expand Down
Loading