-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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`. | ||
|
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
---- | ||
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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