[Qgis-developer] API changes

[Marco Hugentobler]

Hi Martin and QGIS devs,

Nice to see the QGIS API getting better and better.

> You can use QgsField::type() to find out what QVariant type you should
> expect for the field values. Currently QGIS supports String, Int and
> Double. It will be useful to add also DateTime type later. Variant
> type is decided by vector providers. Besides this, there's also
> QgsField::typeName() which reports type as a provider-specific string.

That's very useful to have QgsField::type() returning QGIS specific types. I 
was just about to restore the old numeric/non numeric type lists for 
providers in 0.9. Now I prefer to use QgsField::type() to let the graduated 
symbol dialog decide which attributes to show (no Strings).



I have a further suggestion for API change, which I like to apply to svn in 
the next few weeks. Currently when we go through all the features in a 
provider, we do 
reset()
select(rectangle)
getNextFeature(attributeList).

The possibility to give the attribute list for each getNextFeature call is not 
well suited for the postgres provider. It means, that postgres provider only 
can fetch the geometry via binary cursor, but not the attributes, because 
they can be different ones in each getNextFeature call. So what postgres 
provider does is to make a SELECT call to the database for each feature if 
attributes are required (e.g. classified symbology or opening attribute 
table). It would be much better to have something like
reset()
select(rectangle, attributeList)
getNextFeature()
so that attributes could be fetched with binary cursor. I made some tests by 
doing a quick hack to the postgres provider and the following came out with a 
simple test dataset:

current approach:
rendering geometry only: 4 seconds
classified symbology: 8 seconds
opening attribute table: 12 seconds

proposed approach with select(rectangle, attributeList) and attributes via 
binary cursor:
rendering geometry only: 4 seconds
classified symbology: 4 seconds
opening attribute table: 7 seconds


Regards,
Marco

 

Am Sonntag, 25. März 2007 00:37 schrieb Martin Dobias:
> Hi devs,
>
> in commit 6833 I've done some API changes to trunk. The most important
> one is how feature attributes are handled. Until now, there was
> QgsFeatureAttribute class which contained field name and field value
> (both strings). This approach had some flaws:
> - field name was redundant (one can find out field name from field index)
> - field value was represented as string, making it difficult to
> represent other types
>
> About a year ago we had a discussion on qgis-dev list and spoken about
> the usage of QVariant instead of QString for field values. I decided
> to remove QgsFeatureAttribute class and use just QVariant for values.
> So, now when you access attributes it should look like this:
>
> const QgsAttributeMap& attrs = feature.attributeMap();
> int myIntAttribute = attrs[0].toInt();
> QString myStringAttribute = attrs[1].toString();
> double myDoubleAttribute = attrs[2].toDouble();
>
> You can use QgsField::type() to find out what QVariant type you should
> expect for the field values. Currently QGIS supports String, Int and
> Double. It will be useful to add also DateTime type later. Variant
> type is decided by vector providers. Besides this, there's also
> QgsField::typeName() which reports type as a provider-specific string.
>
> I hope that I haven't caused regressions with these changes, just keep
> in mind that if something with vector layers is not working well that
> might be my fault :-) My other hope is that this pushes QGIS API
> another small step further to be simpler and easier to use. I have in
> mind more changes but these should wait for next release as further
> changes might destabilize trunk rapidly.
>
> Regards,
> Martin
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.qgis.org
> http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer