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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
