[Development] QString behavior change
Thiago Macieira
thiago.macieira at intel.com
Tue Aug 11 17:46:48 CEST 2015
On Tuesday 11 August 2015 10:38:27 Julien Blanc wrote:
> That point is certainly valid, but i would like to raise the point that
> string nullness is a *required* feature for QtSQL (a null QString is
> converted to a NULL SQL, whereas a non-null empty QString is converted
That's a misfeature. QtSql should have been using something like
QOptional<QString> for a nullable string. In addition, it usually uses
QVariant, which has its own null setting -- it allows for a null int, different
from a value of zero.
> to a ''). This makes a huge difference when dealing with not null sql
> fields. The fact that trimming an empty string may make it null is
> counterintuitive, a behaviour change, and not documented.
>
> So, could you consider returning StringType("") instead ? (unless i’m
> wrong, null strings should be handled by the first condition).
No.
If you want to pass a null QString to QtSql, you can. If you want to check
whether a string you got from QtSql is null, you can.
That has nothing to do with trimmed(). Other API doesn't guarantee to keep
null either when mutating strings, so I don't see why we should here. If the
API doesn't specifically deal with null QStrings, expect that it will randomly
change between null and not null.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list