On Fri, Mar 20, 2020 at 9:08 AM Julien Cabieces <julien.cabie...@oslandia.com> wrote: > > > Hi, > > > Hi, can someone explain what is the real logic currently coded for trust > > option? > > It calls the QgsProject::setTrustLayerMetaData(bool) which says > > > Sets the trust option allowing to indicate if the extent has to be read > > from the XML document when data source has no metadata or if the data > > provider has to determine it. > > Moreover, when this option is activated, primary key unicity is not checked > > for views and materialized views with Postgres provider. > > And from what I see from the code it does what it says, no less, no > more. Only for PostGres. > > As a result the variable checkPrimaryKeyUnicity is set to 1 in the uri. > > It also add a trust node in project configuration for every layer, but I > don't see where it's used in QGIS code (I maybe miss something) >
So far so good, but I'd really like to stop having all these differences among providers, there is too much Postgres specific implementation in QGIS now. At least for use estimated metadata, and "trust" options we should agree on a minimal set of provider-agnostic options that the different providers can support and expose through capability flags. The options should be ideally settable per-layer (as part of the data source URI) and with a per-project default that applies when there is no such information in the individual layer URI. My main concern is that we currently have a whole lot of undocumented/hidden behaviors and slight variations among different providers and we should really try hard to homogenize them and eventually converge towards a unified interface with more shared capabilities. Kind regards -- Alessandro Pasotti w3: www.itopen.it _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer