[QGIS-Developer] QGIS "fast" mode

Régis Haubourg regis.haubourg at gmail.com
Thu Mar 19 11:30:19 PDT 2020


Hi, can someone explain what is the real logic currently coded for trust
option? It feels like this topic raises again each year for 5 years now,
and we have regressions and what it is supposed to do.

It was funded at start to not check at all any metadata on the datasource
and read only qgs informations
Did it change for some reason ? Why?

It should be adequate even for big databases of QGIS stores all the
required informations.

Regards
Regis

Le jeu. 19 mars 2020 à 18:05, René-Luc Dhont <rldhont at gmail.com> a écrit :

> Hi Tomas,
>
> The way trust option works is not enough for big databases and big
> project with more than 100 layers. It is what Michaël and I experiment.
>
> Then the problem with changes data is more about the layer extent. For
> example a natural observations layer is designed to accept data on a
> territory but t the start of the project the layer extent is null and
> will growing with data inserted. The trust option cannot be used at the
> project start unless the user can set the available extent, or can
> defined the trust option for each layer.
>
> It will be great to set trust option at the layer level so QGIS can
> trust the layer information provided by the XML : QLR or QGS content
> It will also be great to can set some technical metadata like a layer
> available extent as the geographic area for which a selected CRS is
> valid for use.
>
> Regards,
> René-Luc
>
> Le 18/03/2020 à 22:01, Tomas Straupis a écrit :
> > 2020-03-18, tr, 21:41 kimaidou rašė:
> >> # only few requests are avoided as you pointed out so the performance
> improves "only" a bit
> >    In large databases those few requests take minutes and sometimes
> > even hours... For servers even 30 seconds are too much when you're
> > trying to add a new QGIS server process to existing say 10 while on
> > high load doing 500 requests per second.
> >
> >> # sometimes you have some layers with changing data, and there is
> actually no way to trust only a subset of layers inside the project
> >    1. If geometry types are changing by design, then checking geometry
> > type upon project loading is not enough. Then you need to ALWAYS
> > filter your results by requested geometry type. But only if it is the
> > case of varying geometry types. In my opinion, developer of the
> > layer/query should know beforehand if it is possible for geometry
> > types to variate and then create a view filtering on geometry type (or
> > it could be an option in QGIS ~"filter on geometry type").
> >
> >    2. If database schemas are changing on-line then I would say
> > something is very wrong with the IT processes. Changes should start on
> > dev environment where data changes and QGIS project changes as well.
> > Then changes to db structure go to other environments up to production
> > in patches TOGETHER with updated QGIS project. System (in this case
> > QGIS) should never (in my experience) try to "fix" the problem because
> > it does not know all required information: maybe the project was
> > opened in incorrect environment, maybe it is a temporary problem,
> > maybe the real table is missing and you're accidentally trying to
> > query incorrect table which was never supposed to be queried -> strict
> > rules/control. Of course there could be a button "refresh" on a layer
> > to allow operator to re-query layer information upon manual request.
> >
> >> Do you think it would be interesting to have the trust option per layer
> and not only per project?
> >    Theoretically there could be very different data sources, but in my
> > opinion if organisation uses strict IT processes then all layers will
> > be strictly managed (you would rarely/never have direct access to the
> > database of a different company/institution with different/weaker
> > processes). And vice versa.
> >
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200319/bcfca1ef/attachment.html>


More information about the QGIS-Developer mailing list