diff options
author | Mark Brand <mabrand@mabrand.nl> | 2011-03-29 15:27:17 (GMT) |
---|---|---|
committer | Marius Storm-Olsen <marius.storm-olsen@nokia.com> | 2011-03-29 15:32:43 (GMT) |
commit | 0f15ab4e750690bdb2b649332d5c3276bf24c440 (patch) | |
tree | b5dda26d760ff863ca069c3676cd872affedb290 /tests/shared | |
parent | db860947715d72bf06d48b6de3c096c348e12432 (diff) | |
download | Qt-0f15ab4e750690bdb2b649332d5c3276bf24c440.zip Qt-0f15ab4e750690bdb2b649332d5c3276bf24c440.tar.gz Qt-0f15ab4e750690bdb2b649332d5c3276bf24c440.tar.bz2 |
let generated flag control SQL generation
Previously, if QSqlField's QVariant value had type "invalid", this
caused the field to be omitted in data-changing SQL statements generated
from QSqlRecord edit buffers.
Complaints against this mechanism:
- It precludes initializing value type to field type, which would
otherwise seem sensible and useful, such as when using model.data() in
contexts where the field type is not readily available.
- QSqlField::clear() does initialize value type to match field type and
so is incompatible with this mechanism.
- Problems such as described in QTBUG-13211.
- Unwanted distinction between "invalid" and "null" when mapping field
values to SQL values.
- QSqlField's generated flag already provides a mechanism for
controlling SQL generation.
These complaints are redressed here by replacing this mechanism with
reliance on QSqlField's generated flag. The flag is initialized to false
in new edit records and set to true when a value is set. Applications
can still manipulate generated flags directly to control SQL generation.
Generation of SELECT statements already used the generated flag and is
unaffected by this change.
Merge-request: 1114
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Reviewed-by: Michael Goddard
Diffstat (limited to 'tests/shared')
0 files changed, 0 insertions, 0 deletions