Bug report #15771
@parent not linked to the correct feature when looping through layer
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | Matthias Kuhn | ||
Category: | Expressions | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 23693 |
Description
While testing out the cool new @parent variable for the aggregate() function, I noticed the @parent variable doesn't get assigned to the correct feature when looping through a layer (as part of labelling or symbology rendering). I've attached a small test project which demonstrate the issue.
Steps to reproduce- Open the parent.qgs test project
- Take note of the label over the two orange areas
- It should be showing the number of overlapping points, which it does properly only for the first feature (i.e. 3), while the second feature also shows 3 when it should show 2.
- The labels' second line show the @parent COMM_CODE value, which shows the wrong one for the second feature (it should be 123456, and instead it prints 12345)
Associated revisions
[ogr] Ignore request limit if unable to compile expression
Fix #15771
Fix QgsFeatureRequest with expression not using provider fields
and limit (fix #15771)
Fix QgsFeatureRequest with expression not using provider fields
and limit (fix #15771)
(cherry-picked from 5e3bef7)
History
#1 Updated by Mathieu Pellerin - nIRV about 8 years ago
- % Done changed from 0 to 50
- File parent_v2.zip added
This commit (#7a05a7a8c4b9184f6cad7d155b6714076b1dccd9) improved things (i.e. @parent's caching works, so is $geometry's), but caching is still not updated for "fields" in the filter clause.
I'm attaching an updated test project, which labels two polygons using three aggregate calls, the third one being built on a "field" = attribute(@parent,"parent_field) which fails for the 2nd polygon. The failure is due to "field" not being updated with the 2nd polygon's values.
#2 Updated by Anonymous about 8 years ago
- Status changed from Open to Closed
Fixed in changeset e7333f68145f27a74aacd8f75939623e37fc4510.