I think you got the wrong caption. It's the world if SQLite supported multiple concurent writes.
Stupid transaction deadlocks...
I think you got the wrong caption. It's the world if SQLite supported multiple concurent writes.
Stupid transaction deadlocks...
create table boolean (
id integer primary key,
name text not null unique
)
insert into boolean (name) values ('true');
insert into boolean (name) values ('false');
create table document (
id integer primary key,
name text not null unique,
body text not null,
is_archived not null integer,
foreign key (is_archived) references boolean (id)
on delete cascade
on update no action
);
Solved.
Bonus: DBAs hate this one weird trick that can free up incredible amounts of disk space by deleting just two rows.
Would this make 0 = true and 1 = false?
What do you use instead of booleans ? floats ?
strings "true" and "false" ofc like any sane developer
I got a better one: O for true and N for false.
Seen in production for quite important stuff (payment requests).
O is from Oui, N from Non, of course!
😐🫤
good fucking god
it allows for mood changes, some parts of the code can check charAt(0) == 't'others can do val != 'false' just let it flow.
Use a CHAR(1) you can then use it as an enumeration.
Don't use T/F for true/false use it for the actual sematic meaning for the thing that the Boolean is toggling. E g. S for subscribed, U for unsubscribed, or whatever.
It also means when you inevitably grow to needing a tri-state it makes sense.
Unless SQLite actually supports enumerations, then just use them
I can live without Booleans I think... what saddens me more than nothing else is the lack of more proper treatment for Decimal-like types.
top 32 comments