Up to date it was not possible to create a function that handles NULL values with the
@qgsfunction decorator. As soon as any parameter was NULL, the return value would also
be NULL.
Example of a function that returns a value now with a NULL paramter and would have returned NULL before
```
@qgsfunction(args=-1, group='Custom', handlesnull=True)
def mean_value(vals, feature, parent):
valid_vals = [val for val in vals if val != NULL]
return sum(valid_vals)/len(valid_vals)
```
[FEATURE]
bool(obj) in Python has the following semantics:
1. if the object has __bool__() method, return its value
2. if the object has __len__() method, return its value
3. return True
So for objects in QGIS API that implement __len__() method, we were getting
unexpected behavior - for example, "if layer: ..." would evaluate as False
in case the layer was empty, while the usual expectation is that any reference
to an object that is not None should evaluate to True.
- Adding datasets to mesh layer from properties panel
- Information and source panel in properties panel
- Selection of active dataset (properties or styling panel)
- Styling of contours/scalars (properties or styling panel)
- Styling of mesh frame (properties or styling panel)
- Styling of vector arrows (properties or styling panel)
existing folder match for a path
E.g. if \a path is "/home/user/projects/2018/P4343"
and "/home/user/projects" exists but no "2018" subfolder
exists, then the function will return "/home/user/projects".
(Suprisingly no existing Qt method for this!)
A pseudo color renderer was getting created in classify() but never deleted.
Spotted by @PeterPetrik
As a bonus switched a for loop from mixed constBegin()/end() usage to range for.
message log critical/warning messages
These messages are still logged, but the log indicator is not
modified to flag their appearance.
This allows certain error messages to be logged (e.g. on startup)
which cannot be fixed by users/developers (e.g. those caused
by upstream Qt issues, 3rd party Python libraries, etc) but
without flagging them.
Currently, we get so many of these warnings on startup that the
log indicator loses all impact, and newly introduced, VALID
errors go unnoticed/ignored.
We never call this method using nullptrs, so there's no need
for this to be a pointer argument in the first place. And
having it a pointer encourages leaky code, such as the
leak this commit fixes in server.
For complete support, it requires two GDAL fixes:
- One to avoid feature count to be invalid when using ROLLBACK TO SAVEPOINT
f73ec8cd1d
- Another one to avoid nasty issues, at least on Linux, with the POSIX
advisory locks used by libsqlite that could be invalidated due to how GDAL
could open files behind the back of libsqlite. The consequence of this
could be the deletion of -wal and -shm files, which caused issues in QGIS
(non working iterators when the edit is finished, and later edits in the
same session not working). Those issues could appear for example if doing
ogrinfo on the .gpkg opened by QGIS, or if opening two QGIS session on the
.gpkg
Both fixes are queued for GDAL 2.3.1
