This change is similar to the one introduced in the previous
commit for `QgsAttributes` . The python call of `setAttribute` expects
a `QVariant` as input. sip is able to directly handle `QVariant` but
this allocation can be slow.
In some cases, it is possible to speed-up the `setAttribute` call by
checking the type of the attribute. If the attribute is a boolean, an
integer, a float or a string, it is possible to avoid the intermediate
sip QVariant allocation done by `sipConvertToType`.
Based on some testing, this allows to speed-up a python `setAttribute`
call up to 80%. If the python attribute is already a `QVariant`, then
one get the same time.
The python `QgsFeature.setAttributes()` calls is relatively slow
because of the call to `sipConvertToType` which needs to make in
intermediate allocation for each attribute QVariant creation.
This change aims to speed up this call by avoiding the call to
`sipConvertToType` for the most common types.
The change itself is quite simple. If the input attribute is a
boolean, an integer, a string or a floating, a QVariant is directly
created by using the python C API instead of calling
`sipConvertToType`.
Based on some testing on lists which can contain between 5 and 10
elements, I have measured an acceleration up up to 70%.
This allows us to control the sort order and limit for each expansion,
and gives us more flexibility in future to eg handle per expansion
filter strings
This change allows SensorThings entities to be expanded to contain
their related child feature attributes, exposing the relational
SensorThings model as a traditional "flat" GIS-friendly table
structure.
Eg when selecting Location entities, you can now opt to expand
to "Things > Datastreams > Observations". This would result in
multiple "stacked" point location features, one corresponding
to each observation, with the attributes for each point feature
containing the location, thing, datastream and observation
attributes.
(Best used combined with some extent, feature limit, or custom
filter option, as this can otherwise result in very heavy
requests to the backend service!)
Fixes#56805
Use a tree display for processing history entries, where the root
item for each entry shows the full algorithm log when clicked,
and the python/qgis_process commands are instead shown as child
items
This provides more useful information for users browsing the history,
while still making the all the previous information available
