[Qgis-developer] Vector attribute types compatibility

[kimaidou]

+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 != showing
only "simple types" as float / string / integer / boolean.
Why not store the driver type (for example bigint for postgres) but only
show "simple" correspondance ( integer here). The power users will be able
to see the real driver type in the metadata tab (or anywhere else more
appropriate).

I would love to see only these types in the Field tab : string / float /
integer / boolean

Michael



2013/7/5 Radim Blazek <radim.blazek at gmail.com>

> 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, always returns true.
>
> QgsOgrProvider:
> * mNativeTypes: int(10), double(20,15), string(255), date, datetime
> (the types should be taken from OGR because depend on OGR driver, but
> I don't see any function in OGR to get supported types)
> * addAttributes(): if type is not supported, the field is not added,
> error is set and returns false, supported fields are added however.
> * createEmptyLayer() is using QgsVectorFileWriter which has its own
> field types handling (different from QgsOgrProvider::addAttributes())
> and calls directly OGR_L_CreateField()
> * convertField(): doing the same as QgsVectorFileWriter (copy pasted
> code) but not used at all
>
> QgsPostgresProvider:
> * mNativeTypes: int(0), longlong(0), double (20,20), string(255), date
> (there are more types defined but these are those with max
> lengh/precision per QVariant type)
> * addAttributes(): is using field typeName() to add fields, but
> typeName is always provider specific so it may become problem if
> fields come from another provider. If single field fails, no fields
> are added (transaction) and false is returned
> * createEmptyLayer(): is using convertField() (that is why d'n'd does
> not fail) on all fields and then addAttributes()
> * convertField(): sets field typeName based on type
>
> The problems I see:
> * impossible to take simply fields from one provider and add them to
> another one, for example:
>     * ogr -> memory: numbers are often double(24,15) or date
>     * ogr -> postgres: ogr is using String as typeName which fails as
> type in postgres, postgres mNativeTypes are too short
> * postgres provider addAttribute() takes typeName (which may be
> whatever) as type for add column
> * no method to convert not supported field to a supported one + get
> message (for example, "string cut to 255 characters" or "date
> converted to string"
>
> I believe that, from user point of view, if data are being written to
> a provider which does not supported all data types, then:
> * user should be warned before the data are written, getting a list of
> necessary type conversions and length/precision cuts
> * if confirmed by user, all the data should be written converted to
> supported types
> but there is no support for that in API.
>
> My suggestion:
> * add
>      virtual QgsField QgsVectorDataProvider::supportedField(field, ok,
> message)
>   which would try to convert unsupported field to a supported field
> and set message about conversion, it should almost never fail
> * all methods adding fields (createEmptyLayer, QgsVectorFileWriter)
> should use the same provider addAttributes()
> * provider addAttributes() should first check if all fields are
> supported using supportedField() and add nothing if at least one is
> unsupported (if some fields are not added successive addFeature()
> fails because of different number of attributes)
> * add support for date and datetime to memory provider and set
> benevolent length/precision limits (however it is not correct to set
> size/precision > 15 for double, that is the only way to make possible
> to copy data from OGR)
>
> I am not sure how QgsPostgresProvide::addAttributes() should work,
> because using typeName() may fail for fields from different provider
> while using type() (i.e. convertField()) would disable the possibility
> to specify explicitly postgres type by typeName. This is maybe
> crucial. In general, what defines field type - "type" or "typeName"?
> We could say that if typeName is unknown to postgres, it should use a
> type based on "type" but the same typeName may have different meaning
> for different drivers.
>
> I am talking about 2.1.
>
> Radim
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130705/2390ad5b/attachment.html>