deleted and dead are integers. They are stored as 0/1 rather than booleans.
My fork of arc supports booleans directly.
In other words, I can guarantee beyond a shadow of a doubt that dead and deleted are both booleans, not integers.
In this particular case, I agree that you should record the most raw form. Which would be a boolean column of trues and nulls -perfectly handled by parquet.
"Deleted" and "dead" are separate columns.
> So not only would it not make sense semantically, it would break if a third means were introduced.
If that was the intention, it would seem like a bad design decision to me. And actually what you assume to be the reasoning, is exactly what should be avoided. Which makes it a bad thing.
This is a limitation not because of having the bool value be represented by an int (or rather "be presented as"), but because of the t y p e , being an integer.
Yes, we know!
> If that was the intention, it would seem like a bad design decision to me. And actually what you assume to be the reasoning, is exactly what should be avoided. Which makes it a bad thing.
That is should be avoided is what makes it a bad thing? I am probably on board with the idea that it is bad design, I just don't know what reasoning you are referring to here. How would you design it?
> This is a limitation not because of having the bool value be represented by an int (or rather "be presented as"), but because of the t y p e , being an integer.
What bool value? As designed, it is an int. I'm sure that I am just missing what you are saying.