summaryrefslogtreecommitdiff
path: root/connectivity
diff options
context:
space:
mode:
authorLionel Elie Mamane <lionel@mamane.lu>2012-01-16 19:38:01 +0100
committerLionel Elie Mamane <lionel@mamane.lu>2012-01-17 15:47:43 +0100
commita261e36481c80750ad7b10505e4b05b9873c328d (patch)
treec6f16e995f581c81c684a754ca0fdcd90650e14c /connectivity
parent605707652afebf0e5c90311adcc7767ebe807e45 (diff)
fdo#44813: don't replace NULLs given by the database by type-default values
It makes no sense, because non-nullable columns can have NULL value. E.g. in "foo LEFT JOIN bar ON condition", the non-nullable columns of "bar" when it has no row matching "condition". Even when we are about to insert/update a row, we should not put a hard-coded value (that just happens to be the one constructed by the C++ default constructor for that type) in non-nullable columns: there is no guarantee that this value makes sense in that database's context. The database may or may not have a default value set for that column. If it has, we should leave it up to the database to set it automatically. If it has not, an error *is* the right reaction. Another place where this substitution does damage is when we refresh a row. We use the values we have read from the primary key to select the row again. So we should not mangle those, else the select returns no row and we mistakingly think the row has been deleted.
Diffstat (limited to 'connectivity')
0 files changed, 0 insertions, 0 deletions