On 01/14/2016 07:07 PM, Even Rouault wrote: > 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)
Fair enough, this particular point is unlikely to be significant >> 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. > And it does a good job with it, at least there is GPKG support already! -- Matthias Kuhn OPENGIS.ch - https://www.opengis.ch Spatial • (Q)GIS • PostGIS • Open Source
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer