On Sat, 2012-10-27 at 21:42 +0200, Martin Dobias wrote: > On Sat, Oct 27, 2012 at 2:46 PM, Matthias Kuhn <[email protected]> wrote: > > > > Sounds like something worth considering. > > Something else I have been thinking of and what would increase > > performance pretty good in some situations would be to be able to select > > by an expression: > > > > myFeatureSet = provider.select( QgsExpression( 'attr1 = 1 AND attr2 > 5' > > ) ) > > while myFeatureSet.nextFeature(myFeature): > > do interesting stuff... > > Yes, this is another feature I have in my mind, something that could > be later added to QgsFeatureRequest. Actually for expressions there > are two choices: expressions for QgsExpression and provider's native > expressions (e.g. SQL supported by PostGIS). The difference is that > the former ones should work for any provider, while the latter ones > only for those with some native expression language - those are likely > to be faster since the expression would be executed in the backend, so > less data transfer and thus faster fetching.
The former one (native expressions) should be pretty straightforward to implement and will surely be useful for some very specific tasks and allows to use the full potential of the backend. The later one could be inspired by OpenDBX [1] or similar (I have no personal experience with this. It would be nice if somebody who has could give advice). I would very much like this approach as it would allow developers to support all database backends without additional effort. For the end user there would be a reduced risk for a lock-in [2]. I think this could be implemented in the data-provider as an abstract method, which filters all the data locally. Each data provider can then implement a set of basic expressions supported by the backend to be evaluated there (and maybe fallback in case of new expressions not yet implemented in a specific dataprovider) [1]: http://www.linuxnetworks.de/doc/index.php/OpenDBX [2]: http://en.wikipedia.org/wiki/Vendor_lock-in Matthias _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
