quivr
quivr copied to clipboard
Write up docs on caveats around nullable subtables with non-nullable fields
288e29109cba53a36b281bb47de2dca0f259b4f9, eae03894e60de410cf5b590cedd4903f526373a3, and fa916b2dc3e04a9ebd2763010d1533a22f6b57cd were three commits dealing with one tricky issue: what do we do when a Table has a nullable subtable column, but the subtable itself has non-nullable fields?
Those commits deal with this situation in a somewhat unsatisfactory way: they rewrite the subtable's schema to accept null values.
This has the unfortunate effect of breaking the expectations of the subtable. Now its columns could have null values.
This should be documented, and explained. There's no real good way around it currently, since the subtable is implemented in such a transparent way. It would be good to think about better solutions, like maybe using a validity bitmap for subtables, allowing for at least some sort of filtering to only look at valid rows of a subtable.