[Qgis-user] Relation (1-N) Unpredictable Result (with default options)

Tue Sep 15 11:15:05 PDT 2020

Hi Jeffrey,

Ah - this sounds familiar. I am cc'ing Denis Rouzaud who fixed this on 
master.

See https://github.com/qgis/QGIS/issues/37266

@Denis - was this ever backported to 3.10? From 
https://github.com/qgis/QGIS/pull/37286 I can't tell.

If this isn't fixed in 3.10 yet, I strongly suggest to do so.

Thanks for a clarification, Denis,

Andreas

Am 15.09.20 um 17:50 schrieb Jeffrey Durrence:
> Andreas,
>
> Thank you for your interest in my reported problem.  I have worked 
> with this some today in hopes of opening an issue on GitHub.  
> Unfortunately, the problem seems even more mysterious to me after 
> further testing.
>
> I have 2 data data tables generated extracted from a fulcrumapp.com 
> app.  These 2 tables have a foreign key relationship by design, so 
> they should work well in QGIS using the relation feature.  After 
> today's testing, I can tell you that they actually do work fine so 
> long as I use a very small subset of the actual data.  This is the 
> mysterious part.  For example, if I limit the parent table to only 10 
> records and then limit the child table to those records linked to the 
> 10 parents, QGIS performs as expected.  If I use all of the data 
> (around 4000 parent records and 9000 child records), then I get an 
> incorrect parent-to-child assignment for new child records that I try 
> to create.
>
> With this being the case, I don't feel confident posting an issue on 
> GitHub.  I would have to anonymize the data to post on GitHub, and 
> that would require further work on my end.  If I have more time today 
> or tomorrow, I will try to further investigate the problem to see if I 
> can learn more about the behavior.
>
> -Jeffrey
>
> --
> Jeffrey Durrence
> jeffrey.durrence at mcleanengineering.com
> McLean Engineering Company
> 815 South Main Street
> Moultrie, GA  31768
> 1.229.985.1148 (Voice)
> 1.229.985.2248 (FAX)
> 1.229.798.0480 (Mobile)
>
> ------------------------------------------------------------------------
> *From: *"Andreas Neumann" <a.neumann at carto.net>
> *To: *"Jeffrey Durrence" <jeffrey.durrence at mcleanengineering.com>
> *Cc: *"qgis-user" <qgis-user at lists.osgeo.org>
> *Sent: *Tuesday, September 15, 2020 2:12:12 AM
> *Subject: *Re: [Qgis-user] Relation (1-N) Unpredictable Result (with 
> default options)
>
> Hi Jeffrey,
>
> Can you please open an issue on Github 
> (https://github.com/qgis/QGIS/issues) and include your DDL SQL 
> statements you used for these tests - including all pkey/fkey and 
> other constraints you used and a simple QGIS project file 
> demonstrating the issue. It is easier to discuss such issues on Github.
>
> Maybe it is related to the fact that Comboboxes aren't properly 
> initialized with NULL values, for cases that don't allow NULL values.
>
> This is important to investigate - as it is unacceptable that corrupt 
> data is collected.
>
> Thanks,
>
> Andreas
>
> On 2020-09-15 04:32, Jeffrey Durrence wrote:
>
>     Today I was trying to set up an edit form for a spatial table with
>     a related, non-spatial table.  I have done this many times in the
>     past, but it's been a while.  After using Project Properties to
>     set up my relation, I made several attempts to add a new record in
>     the "child" table.  Each time I tried, the new record did not get
>     the correct value for the field which relates the two tables. 
>     Existing records were displayed as expected and could be edited,
>     but I could not add new features.
>     I went to the docs to see if something had changed that might be
>     affecting me.  I downloaded sample shapefile data and used that to
>     demonstrate that related records could be created with that data. 
>     I set up a clean database and QGIS project file and made several
>     attempts with my PostGIS data.  I did observe that some new
>     options were available to me under the widget area of the child
>     table.  What had me confused was that with the default options
>     selected (the way I used to do it), the "reference field" values
>     generated for the "new" child records were real values -- just not
>     at all the correct values.
>     I tried several things with the PostGIS data, but what finally
>     fixed the behavior for me was to make one change in the default
>     Widget settings for the "reference field" in the child table
>     properties.  In my case, enabling the option to "Use a read-only
>     line edit instead of a combobox" resolved the issue.  When that is
>     enabled, new child records get the correct value for the reference
>     field.  I don't completely understand what determined the inserted
>     values when this option was not enabled,  but I would think that
>     enabling this by default would save a lot of confusion for users
>     like me.  I was quite surprised that I could not find folks
>     talking about this in the usual places.  Could be that there is
>     something local to my environment, but I thought it worth
>     mentioning should someone else stumble upon it.
>     Using QGIS LTS (3.10.5) on Ubuntu 20.4 and Windows 10 64-Bit with
>     PostGIS backend (observed same behavior with Postgres 10.14 /
>     PostGIS 2.4.4 and Postgres 12.4 / PostGIS 3.0.0)
>     --
>     Jeffrey Durrence
>     jeffrey.durrence at mcleanengineering.com
>     McLean Engineering Company
>     815 South Main Street
>     Moultrie, GA  31768
>
>
>     _______________________________________________
>     Qgis-user mailing list
>     Qgis-user at lists.osgeo.org <mailto:Qgis-user at lists.osgeo.org>
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20200915/2e9c94f3/attachment.html>