Le 27/05/2014 15:03, Régis Haubourg a écrit : > Hugo Mercier wrote >> Or >>> calculated fields in view can't be explicitly cast, so QGIS should have >>> to >>> guess data type based on a data scan (a major unadressed issue of sqlite) >> >> Hmmm I wasn't aware of this limitation in SQLITE views :( > > Yes, SQLITE does dynamic typing, so user or provider has to scan values to > guess the right type. > Here is a sqlite topic on that [0] > And here my initial post in qgis list [1] > > [0] > http://sqlite.1065341.n5.nabble.com/Computed-columns-in-VIEWs-return-NULL-but-should-be-able-to-be-typed-Any-ideas-td56769.html#a56770 > > [1] > http://osgeo-org.1560.x6.nabble.com/Spatialite-can-t-type-fields-of-a-view-td5058436.html
Hi, Still on this topic. I made a few tests with sqlite views. Indeed you cannot enforce a particular column type, but : * you can convert values with CAST (casting 'foobar' to integer gives 0), even if the resulting type is undefined * QGIS does not seem to have any particular problem with untyped SQLite columns, they will be reported as TEXT (QString) in the layer properties * Even if the column is untyped, each value has its own type. So if a column results from a CAST, to integer say, then the corresponding attribute will be in a QVariant typed as an integer when it is fetched. You can then use this value in a QgsExpression or a categorized symbology as an integer. Am I missing other use cases where not having a column type is a problem ? _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
