[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