I would like to create a cascading select in QGIS using the value relations widget. I'm using QGIS 3.14 (pi) and all layers are stored in a geopackage. The geopackage shown in this example can be downloaded here for testing (project file is in the gpkg).

I am able to do this in terms of limiting available values based on the value of a previously set attribute. However, the attribute table does not honour my choice.

I have a "parent" table with a 'key' and a 'type':


1  |A
2  |B
3  |C   

I have a "child" table as follows:


1       |A        |Yellow
1       |A        |White
1       |A        |Red
2       |B        |Pink
2       |B        |Orange
2       |B        |Green
3       |C        |Brown
3       |C        |Blue
3       |C        |Black

I create a point layer "test" with the attributes of 'testType' and 'testSubtype'.

In the properties > attribute form I set the widget for the 'type' attribute to "value relation" with the following settings:

type value relation settings

I set the widget for the 'subtype' attribute to "value relation" with the following settings:

enter image description here

The filter expression is set to:

"typeChild" = current_value('testType')

This works to filter the options available when adding a new point feature:

cascading select

However when I check the attribute table only the first option for that type shows:

attribute table error

I can alter the 'testSubtype' value in the attribute table by selecting 'order by value' in the Attributes Form setting:

order by value

The desired behaviour is for the attribute table to honour the user's selection and for that selection to persist. Other answers to similar questions on SE link to this post in the QGIS changelog. The workflow above mirrors the behaviour shown in the changelog but changes do not persist.

I'd like to know if this is reproducible behaviour. I've tested this on QGIS 3.2, 3.4 3.10 and 3.14. I get the same results in all versions.

The extra columns in the parent and child tables ('key' and 'keyChild') are for testing different options in the Attribute Form settings prompted by the answer to this issue on github.


Gabriel's answer is accepted. I had failed to realise that the Filter Expression will still work regardless of what is set in the 'key' and 'value' settings of the widget. The key must be unique. Keeping everything the same as descirbed above just changing the key to 'subtype' worked as shown below:

enter image description here

  • When you commit the changes to the geopackage contained database, your selection of Green subtype seems to not being recorded. Please check the logs when you save the changes to the layer after creation of feature. The widget works fine, problems are generally trying to define the relation in the project or in the source database. – Gabriel De Luca Aug 3 at 22:10
  • Thanks Gabriel. Does that mean I need to create a one to many relation (parent -> child) before the state can be saved? I sshould addd that the edits have been saved in that last gif. 'testSubtype' shows as 'Pink' until Order by value is checked. Then 'testSubtype' shows 'Green'. The third option for type B is 'Orange' but that will never be recorded given the behaviour described above. – Oliver Burdekin Aug 3 at 22:39
  • You can press the save button and check in the logs if the values were saved. No, you don't need to create the relation, I think that you have created the relation and there was the problem. If that is not the problem, the key column = "typeChild" in the subtype widget is the problem, it is not a key column since it has duplicated values (A,A,A,B,B,B,C,C,C), you are storing a 'B' value in the testSubtype field and QGIS is showing you the first value 'Pink' associated to the 'B' key. Your Child table has not a unique key, or its key value is stored in the subType field, choose it. – Gabriel De Luca Aug 4 at 0:13

In the Value Relation widget, the Key Column option is the column with the values that will be stored in the table, and the Value Column option is the column with the values that QGIS will show (instead of the key) in the attribute.

A Key Column must have unique values to avoid your behaviour, but the child table has not a key column.

The only column with unique values is subType. You can choose subType field as Key and Value columns, or you can create a unique values field and store that value but showing the subType related one.

Also, it is relevant that you check in the logs that, when you press the save button (or disable the edit mode and choose to save the changes), the commit to the source table was succesfull (if you have created a relation in the project or some constraints in the source table it may fail).

| improve this answer | |
  • 1
    Thanks Gabriel. The setting of the key to 'subType' worked. I had misunderstood that the filter definition will still work irrespective of the key and value settings. – Oliver Burdekin Aug 4 at 9:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.