Le jeudi 14 janvier 2016 18:49:40, Matthias Kuhn a écrit : > On 01/14/2016 06:32 PM, Even Rouault wrote: > > Le jeudi 14 janvier 2016 18:04:00, Matthias Kuhn a écrit : > >> On 01/14/2016 05:42 PM, Even Rouault wrote: > >>>> It will benefit from expression compiling (for filtering and order by) > >>>> which results in performance improvements when it can be applied. > >>> > >>> I'm not completely sure to know what you refer to in the QGIS context > >>> but the OGR SetAttributeFilter() method is directly evaluated by the > >>> SQLite request engine as a WHERE clause, and similarly for the > >>> ExecuteSQL() API. > >> > >> It tries to compile QgsExpressions to native SQL syntax. > >> > >> I think the point of using OGR that it offers an awesome abstraction > >> layer where the consumer doesn't need to care about the backend. > >> > >> As soon as ExecuteSQL is used this abstraction no longer applies and it > >> just adds another layer of uncertainty (different library versions...) > >> and may potentially hide internals of the backends which may be useful > >> in some cases (datatypes, backend metadata, available indexes, ...), so > >> the advantage is gone while it complicates advanced topics. > >> Or did I miss something? > > > > - datatypes: all the ones listed in "Table 1. GeoPackage Data Types" > > http://www.geopackage.org/spec/#_sqlite_container have an OGR equivalent > > - backend metadata: not sure what you're thinking exactly too. But at > > some point this has to be translated in the QGIS abstraction too, no ? - > > available indexes: not present in the OGR abstraction currently (but the > > abstraction can be extended if needed, as it has been done in the past). > > Is QGIS aware of which indices exist ? > > > > A possibility would be to have a thin GeoPackage provider (I guess it > > could probably even by generic to most OGR drivers that have native > > SQL92 capabilities) extending the base OGR one + using its capabilities > > with the specificities of GPKG (eg adding the SORT BY clause). Or a more > > quick&dirty way would be to hack that directly in the OGR provider for > > the vetted OGR drivers. > > I was referring to databases in general (expression compilation is also > done for MSSQL, Oracle, Postgres) > > I do not doubt that for every requirement an interface can also be > implemented in OGR but it still adds an extra roundtrip in the > development cycle, its presence has to be guaranteed on the client > system (we're still at 1.10.x on win, not sure about all linux distros > and mac) and an extra layer of possible errors, performance loss...
I can understand those reasons (althoug I'm a bit skeptical about the performance loss. That would mean the translation from OGRFeature to QGISFeature becomes really significant in performance profiles) > > What would be the advantage of using OGR when using ExecuteSQL? Just that the GPKG driver already exists (that was my main point) and in theory GDAL/OGR is the natural place to deal with file formats. -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
