In QGIS 3.4 there is the new feature that warns users about a potential data loss
when closing a project that contains memory layers. It displays the warning:
> This project includes one or more temporary scratch layers.
> These layers are not saved to disk and their contents will be
> permanently lost. Are you sure you want to proceed?"
While this is useful in general, there are various cases when this warning
is unwanted. For example, when a plugin creates memory layers by extracting data
from some custom data format (and possibly also writes changes from temporary
layers back to the data storage). In such situations the warning is very confusing
for the users who are unaware of the internals.
This commit adds a custom property "skipMemoryLayersCheck" to map layers,
so if all temporary layers have this property set to non-zero value the warning
will not show up.
layer.setCustomProperty("skipMemoryLayersCheck", 1)
Some rationale on this change...
Previously when applying a "regular" subset string, ie. one that is only the
content of a where clause, we issued a full "SELECT * FROM layer WHERE subsetstring",
resulting in a OGR SQL layer. The caveat of that is that most OGR drivers
will have issues retaining the original FID. A hack consisting in adding a
{original_fid_name} as orig_ogc_fid to the select columns was introduced in
4ce2cf1744
to try to retain the original FID, but this added a lot of complexity. And
actually, in the case of the OGR GPKG driver, it caused it to still be confused
when analyzing the column definition of the resulting layer, since it sees
2 FID columns despite the renaming (one included in the '*' wildcard, and the
one of orig_ogc_fid), which caused it to use sequential FID numbering (the
driver when seeing more than once a column that is the FID column assumes that
some cross join is done, and thus that FID are unreliable)
A simpler and more robust (crossing fingers!) approach in that case is
just to use OGR_L_SetAttributeFilter() instead of GDALDatasetExecuteSQL().
Some care must be taken to cancel the filter when removing the subset
filter, or in QgsOgrFeatureIterator when combining with the filter
expression coming from the request, but besides that, this is more
straightforward, and actually solves #20136
