Error when adding child feature and different ID value in Qfield and QGIS

Ask the Community
1

Hello everyone,

I’m currently working on a Qfield project in offline editing dealing with different PostGIS layers to be updated on field. The last test resulted in a series of problem connected to the element ID value stored and visibile in Qfield and the corresponding one in the syncronized QGIS project. Also, a layer that is part of a 1:n relationship does not allow to add a child element in its form in Qfield environment showing the following error message: “Cannot add child feature: parent primary keys are not available”. I don’t know if this two issue are connected.

Reproduction Steps:

  1. Preparation of the project in QGIS 3.16 for the export in Qfield 1.10 in editing offline. The project contains PostGIS point layers and one of them has a 1:n relation with another table.
  2. Export for Qfield using the Qfield Sync plugin
  3. Opening the project in Qfield and adding a new point to the parent layer
  4. Adding with the add-button the child element inside the parent form

Expected behavior:

Qfield opens the child form for editing all the needed attributes for the child element before saving.

Observed behavior:

The error “Cannot add child feature: parent primary keys are not available” appears on screen and the child form doesn’t open.
Also, ID is always equal to 0 for each new parent element while, after importing the project back in QGIS, a different number ID is stored in the Attribute Table.

This happens only with newly created element in the parent layer. It does not happen with element already existing in the parent layer in the project for which it is easily possible to add child features as expected.

Screenshots and GIFs

ID visible in Qfield
ID visible in Qfield1200×1920 139 KB

ID stored in Attribute Table after importing in QGIS
ID stored in Attribute Table after importing in QGIS1002×642 58.9 KB

Error message in Qfield
Error message in Qfield1200×1920 195 KB

QField version: [Qfield 1.10 (1da006)]

Additional information:

  • Problem started happening recently, didn’t happen in an older version of QField: [Yes]
  • Problem can be reliably reproduced, doesn’t happen randomly: [Yes]
  • Problem happens with all files and projects, not only some files or projects: [Yes]

Thanks in advance for your kind support and help in understanding and solving this issue,

Federica

Imported from GitHub discussion by @Tars4815 on 2021-12-15T11:01:07Z

2

Did you configure a default value for the id field in qgis?
Qfield needs to be able to generate a unique id without a database connection if you are working offline

Imported from GitHub comment by @m-kuhn on 2021-12-15T21:36:59Z

3

Thanks m-kuhn for your help!
I defined as maximum(“id”) + 1 the defult value for the id field of both the parent and the child tables. Also, I checked the “Apply default value on update” box.

Cattura
Cattura1238×744 53.3 KB

In this way, the editing in QField works fine, indicating increasing values for the ID and making possible to include the information of the 1:n relation elements. However, when I syncronize the project back in QGIS, I obtain the following PostGIS error regarding the 1:n relation and its foreign key (even if the element with the id_grupposegnale=43 is visible in the table “t_grupposegnale”:

Insert or update on table “r_segnalefisico” violates foreign key constraint “fk_segnalefisico”
DETAIL: Key (id_grupposegnale)=(43) is not present in table “t_grupposegnale”.

So, in the “updated” QGIS project after the sync procedure I can see the newly added parent elements but without the associations to their child(ren) feature(s). The children features, however, are correctly stored in their non spatial table.

This is an example of the exported Qfield project for offline editing in which the problem occurs:
Project File

Am I missing any particular steps in setting the offline editing?
I’ve also tried these settings but it seems they do not help in solving the issue.

Thanks again in advance for the support!

Imported from GitHub comment by @Tars4815 on 2021-12-22T15:34:47Z

4

The approach which is taken here with maximum(id) + 1 and apply default value on update explains some issues.

  • “Apply default values on update” will repeatedly generate new numbers on every edit and even on sync. This defeats one commonly desired property of primary keys, that they are stable.
  • maximum(id) + 1 works good enough if you have one single device at a time and the complete dataset on the field. As soon you have multiple devices or only a partial dataset, this bears a risk of creating conflicting ids.

Imported from GitHub comment by @m-kuhn on 2021-12-29T07:22:29Z