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@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Matthias Kuhn matth...@opengis.ch <mailto:matth...@opengis.ch> +41 (0)76 435 67 63 <tel:+41764356763> OPENGIS.ch Logo <http://www.opengis.ch>
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
