On 21/08/2014 00:07, Thiago Macieira wrote: > On Wednesday 20 August 2014 20:49:03 Marc Mutz wrote: >> I don't find the QVariant::isNull behaviour any useful or intuitive. It's >> too smart. You can always use v.value<T>().isNull() because value() will >> return a default-constructed T if invalid. > I agree it's not intuitive, but it's there and this feature is used by QtSql. > > When getting a nullable column, a null entry is signalled by a typed QVariant > for which isNull() == true. > > I'd have preferred that QtSql use optionals to indicate such columns: > > varchar => QOptional<QString> > varchar not null => QString
QString may not be the best example, as it already supports the nullability concept, which makes QOptional<QString> quite useless... > The question I have is: how can we prepare a transition from current state > (both a QString) in such a way that doesn't break existing code? > > Should it be a connection-time option for QSqlDatabase? Maybe a query-time > option? Do you mean that you would change QSqlRecord::value to return, instead of a QVariant that can be null, a QVariant holding either an optional or a non-optional object ? I don’t see any advantages in doing so. That would make sense if you could get rid of the whole QVariant stuff, but that would imho need a complete redesign of QtSql. Otherwise, it’ll just add an extra layer, not providing any usefull feature (QVariant already does the job quite well in providing the nullability feature). Regards, Julien _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
