[QGIS-Developer] issues with 1:n relations

[Matthias Kuhn]

Hi Giovanni

On 04/17/2018 06:23 PM, Giovanni Manghi wrote:
> Hi all,
>
> I have recently had to test some scenario with 1:n relations in QGIS
> and I have found a few issues and would like to know if someone has
> them in its pipeline/todo list, eventually to share the effort for the
> fixes.
>
> Anyway I'm also interested on your feedback on the matter.
>
> 1) 1:n relations in QGIS3. They seems unusable at the moment. When
> opening a parent layer feature form, the area/space where the child
> records should show does not show/cannot be expanded.
>
Interesting, I cannot reproduce this here on Linux nor did I hear of
this from our clients using Windows.

>
> 2) 1:n relations in QGIS 2.18.
>
> I have tried a scenario (that to me seems not unusual at all) where
> both the parent and the child are layers/tables with a geometry.
>
> The case where the child has its own geometries does not seems well
> implemented (if implemented at all) in the context of the relation
> feature form and this causes the following:
>
> a) from within the parent feature form, if I edit the child and try
> add a new record there is no tool to allow also add/digitize the
> proper geometry. The user can still enter only the attributes and when
> saving I have seen two things happen *) In a test project using GPKGs
> this led effectively to a record orphaned of its geometry *) In a test
> project using PostGIS layers the edits are *silently* discarded, no
> warning, no error, not even in QGIS logs.

>From what I can remember, yes, there is still an issue here that the
geometry cannot be digitized right at this time. As a workaround one can
go to the attribute table and select this feature and use the add part
tool. In some project we implemented a python based feature action that
implements this use case. (Hint hint, if there's a customer request for
this, I'll be happy to estimate the required amount of work ;) ).

>
> b) from within the parent feature form, when toggling editing for the
> child, this is effectively put it in edit state also in the layers
> panel. So a user can "move away" the parent feature form (that it is
> on first plane) and use the standard editing tools to add a geometry
> to the child layer. When finished the attributes form pop-up and can
> be used to fill the data, with the important issue/limitation that the
> "referencing field" is *not* automatically filled as it is done when
> working within the relation form. Once saved the new record will also
> show in the relation form. This seems a partial workaround because as
> said the referencing field is not automatically filled.

Are you referring to the case here, when the parent is added (and not
edited)
for this case you preferably
 * enable transaction mode
 * server side evaluation of default values (so the id of the parent is
known already at form time before the parent is committed to the layer)
 * deferred foreign key constraints (so the database only checks if the
foreign key points to a valid parent at transaction commit time)

I hope this helps at least a bit
Matthias

>
> Am I missing something?
>
> thanks in advance for your feedback.
>
> cheers
>
> -- Giovanni --
>
>
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Matthias Kuhn
matthias at opengis.ch <mailto:matthias at opengis.ch>
+41 (0)76 435 67 63 <tel:+41764356763>
OPENGIS.ch Logo <http://www.opengis.ch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180417/9e6e71d6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 6671 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180417/9e6e71d6/attachment-0001.png>