On Sun, Jul 7, 2013 at 12:26 PM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Hi Radim
Thanks for raising this important point.
but the same typeName may have different meaning
for different drivers
How about passing a string that tells the origin provider string? The data
On Tue, Jul 9, 2013 at 5:23 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:
What circumstances do exist, where we are not be able to determine the
native type based upon QgsField metainformation, but without using
typeName?
I cannot come to any case at this moment.
I think we should focus on
What circumstances do exist, where we are not be able to determine the
native type based upon QgsField metainformation, but without using
typeName?
I think we should focus on the development on an unambiguous type
schema (QgsFields) and only use the typeName (with provider
information?) as a
Hi Radim
Thanks for raising this important point.
but the same typeName may have different meaning
for different drivers
How about passing a string that tells the origin provider string? The
data provider could then recognise if it comes from the same provider
and use the native types. If
I would like to ask how vector attribute types conversion between
providers is supposed to work. Currently:
QgsMemoryProvider:
* mNativeTypes: int(10), double(20,5), string(255)
* addAttributes() silently skips the field if type is not Int, Double
or String, does not test length and precision,
+1 for clarifiying the use of types in QGIS. It is very hard for
non-developers users to understand the concepts behind, and the differences
between real, double, float / int, integer, int4, int8 / varchar, char,
text, string / etc.
The hard part would be to let the drivers use specific types
