[prev in list] [next in list] [prev in thread] [next in thread]
List: qgis-user
Subject: Re: [Qgis-user] Relation (1-N) Unpredictable Result (with default options)
From: Jeffrey Durrence <jeffrey.durrence () mcleanengineering ! com>
Date: 2020-09-22 18:44:56
Message-ID: 47528087.469184.1600800296082.JavaMail.zimbra () mcleanengineering ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Denis,
Thank you for the follow-up. I did install the latest LTS (3.10.9) yesterday to see \
if things were any different. I confirmed today that the behavior is unchanged, and \
there's no reason why it should be any different based on your message.
For me the simple workaround is to enable the Widget Type Option "Use a read-only \
line edit instead of a combobox." With this enabled, the "parent" field is populated \
as expected.
Thanks for your contributions to QGIS,
Jeffrey
--
Jeffrey Durrence
jeffrey.durrence@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: "Denis Rouzaud" <denis.rouzaud@gmail.com>
To: "Andreas Neumann" <a.neumann@carto.net>
Cc: "Jeffrey Durrence" <jeffrey.durrence@mcleanengineering.com>, "qgis-user" \
<qgis-user@lists.osgeo.org>
Sent: Tuesday, September 22, 2020 8:16:35 AM
Subject: Re: [Qgis-user] Relation (1-N) Unpredictable Result (with default options)
Hi All,
Backporting doesn't seem easily possible and I am afraid of unseen side effects.
A simple fix would be to increase the fetching limit of the relation editor by doing: \
QgsSettings().setValue("maxEntriesRelationWidget", 1000, QgsSettings.Gui )
(the default limit in 3.10 is 100)
Best wishes,
Denis
Le mar. 15 sept. 2020 Ã 20:15, Andreas Neumann < [ mailto:a.neumann@carto.net | \
a.neumann@carto.net ] > a écrit :
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 | \
https://github.com/qgis/QGIS/issues/37266 ]
@Denis - was this ever backported to 3.10? From [ \
https://github.com/qgis/QGIS/pull/37286 | 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:
BQ_BEGIN
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 [ http://fulcrumapp.com/ | \
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
[ mailto:jeffrey.durrence@mcleanengineering.com | \
jeffrey.durrence@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" [ mailto:a.neumann@carto.net | <a.neumann@carto.net> ]
To: "Jeffrey Durrence" [ mailto:jeffrey.durrence@mcleanengineering.com | \
<jeffrey.durrence@mcleanengineering.com> ]
Cc: "qgis-user" [ mailto:qgis-user@lists.osgeo.org | <qgis-user@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 | \
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:
BQ_BEGIN
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
[ mailto:jeffrey.durrence@mcleanengineering.com | \
jeffrey.durrence@mcleanengineering.com ] McLean Engineering Company
815 South Main Street
Moultrie, GA 31768
_______________________________________________
Qgis-user mailing list
[ mailto:Qgis-user@lists.osgeo.org | Qgis-user@lists.osgeo.org ]
List info: [ https://lists.osgeo.org/mailman/listinfo/qgis-user | \
https://lists.osgeo.org/mailman/listinfo/qgis-user ]
Unsubscribe: [ https://lists.osgeo.org/mailman/listinfo/qgis-user | \
https://lists.osgeo.org/mailman/listinfo/qgis-user ]
BQ_END
BQ_END
[Attachment #5 (text/html)]
<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; \
color: #000000"><div>Denis,<br></div><div><br data-mce-bogus="1"></div><div>Thank you \
for the follow-up. I did install the latest LTS (3.10.9) yesterday to see if \
things were any different. I confirmed today that the behavior is unchanged, \
and there's no reason why it should be any different based on your message.<br \
data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>For me the simple \
workaround is to enable the Widget Type Option "Use a read-only line edit instead of \
a combobox." With this enabled, the "parent" field is populated as expected.<br \
data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Thanks for your \
contributions to QGIS,<br data-mce-bogus="1"></div><div><br \
data-mce-bogus="1"></div><div>Jeffrey<br data-mce-bogus="1"></div><div><br></div><div \
data-marker="__SIG_PRE__">--<br>Jeffrey \
Durrence<br>jeffrey.durrence@mcleanengineering.com<br>McLean Engineering \
Company<br>815 South Main Street<br>Moultrie, GA 31768<br>1.229.985.1148 \
(Voice)<br>1.229.985.2248 (FAX)<br>1.229.798.0480 \
(Mobile)<br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div \
data-marker="__HEADERS__"><b>From: </b>"Denis Rouzaud" \
<denis.rouzaud@gmail.com><br><b>To: </b>"Andreas Neumann" \
<a.neumann@carto.net><br><b>Cc: </b>"Jeffrey Durrence" \
<jeffrey.durrence@mcleanengineering.com>, "qgis-user" \
<qgis-user@lists.osgeo.org><br><b>Sent: </b>Tuesday, September 22, 2020 8:16:35 \
AM<br><b>Subject: </b>Re: [Qgis-user] Relation (1-N) Unpredictable Result (with \
default options)<br></div><div><br></div><div data-marker="__QUOTED_TEXT__"><div \
dir="ltr">Hi All,<br><div>Backporting doesn't seem easily possible and I am afraid of \
unseen side effects.</div><br><div>A simple fix would be to increase the fetching \
limit of the relation editor by \
doing:</div><br><div>QgsSettings().setValue("maxEntriesRelationWidget", 1000, \
QgsSettings.Gui )<br></div><br><div>(the default limit in 3.10 is \
100)</div><br><div>Best wishes,</div><br><div>Denis</div><br></div><br><div \
class="elided-text"><div dir="ltr">Le mar. 15 sept. 2020 Ã 20:15, Andreas \
Neumann <<a href="mailto:a.neumann@carto.net" target="_blank" rel="nofollow \
noopener noreferrer">a.neumann@carto.net</a>> a écrit :<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb( 204 , \
204 , 204 );padding-left:1ex">
<div>
<p>Hi Jeffrey,<br>
</p>
<p>Ah - this sounds familiar. I am cc'ing Denis Rouzaud who fixed
this on master.<br>
</p>
<p>See <a href="https://github.com/qgis/QGIS/issues/37266" target="_blank" \
rel="nofollow noopener noreferrer">https://github.com/qgis/QGIS/issues/37266</a><br \
data-mce-bogus="1"></p> <p>@Denis - was this ever backported to 3.10? From <a \
href="https://github.com/qgis/QGIS/pull/37286" target="_blank" rel="nofollow noopener \
noreferrer">https://github.com/qgis/QGIS/pull/37286</a> I can't tell.</p>
<p>If this isn't fixed in 3.10 yet, I strongly suggest to do so.</p>
<p>Thanks for a clarification, Denis,</p>
<p>Andreas<br>
</p>
<div>Am 15.09.20 um 17:50 schrieb Jeffrey
Durrence:<br>
</div>
<blockquote>
<div style="font-family:'arial' , 'helvetica' , \
sans-serif;font-size:12pt;color:rgb( 0 , 0 , 0 )"> <div>
</div>
<div>Andreas,<br>
</div>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
<div>I have 2 data data tables generated extracted from a
<a href="http://fulcrumapp.com" target="_blank" rel="nofollow noopener \
noreferrer">fulcrumapp.com</a> 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.<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>-Jeffrey<br>
</div>
<div><br>
</div>
<div>--<br>
Jeffrey Durrence<br>
<a href="mailto:jeffrey.durrence@mcleanengineering.com" target="_blank" \
rel="nofollow noopener noreferrer">jeffrey.durrence@mcleanengineering.com</a><br> \
McLean Engineering Company<br> 815 South Main Street<br>
Moultrie, GA 31768<br>
1.229.985.1148 (Voice)<br>
1.229.985.2248 (FAX)<br>
1.229.798.0480 (Mobile)<br>
</div>
<div><br>
</div>
<hr id="gmail-m_4277192089278253247zwchr">
<div><b>From: </b>"Andreas Neumann"
<a href="mailto:a.neumann@carto.net" target="_blank" rel="nofollow noopener \
noreferrer"><a.neumann@carto.net></a><br> <b>To: </b>"Jeffrey Durrence"
<a href="mailto:jeffrey.durrence@mcleanengineering.com" target="_blank" \
rel="nofollow noopener \
noreferrer"><jeffrey.durrence@mcleanengineering.com></a><br> <b>Cc: \
</b>"qgis-user" <a href="mailto:qgis-user@lists.osgeo.org" target="_blank" \
rel="nofollow noopener noreferrer"><qgis-user@lists.osgeo.org></a><br> \
<b>Sent: </b>Tuesday, September 15, 2020 2:12:12 AM<br> <b>Subject: </b>Re: \
[Qgis-user] Relation (1-N) Unpredictable Result (with default options)<br>
</div>
<div><br>
</div>
<div>
<p>Hi Jeffrey,</p>
<p>Can you please open an issue on Github (<a \
href="https://github.com/qgis/QGIS/issues" rel="nofollow noopener noreferrer nofollow \
noopener noreferrer" target="_blank">https://github.com/qgis/QGIS/issues</a>) 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.</p>
<p>Maybe it is related to the fact that Comboboxes aren't
properly initialized with NULL values, for cases that don't
allow NULL values.</p>
<p>This is important to investigate - as it is unacceptable
that corrupt data is collected.</p>
<p>Thanks,</p>
<p>Andreas</p>
<p id="gmail-m_4277192089278253247reply-intro">On 2020-09-15 04:32, Jeffrey \
Durrence wrote:</p>
<blockquote style="padding:0px 0.4em;border-left:2px solid rgb( 16 , 16 , \
255 );margin:0px"> <div>
<div>
<div style="font-family:'arial' , 'helvetica' , \
sans-serif;font-size:12pt;color:rgb( 0 , 0 , 0 )"> <div>
</div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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)</div>
<div> </div>
<div>--<br>
Jeffrey Durrence<br>
<a href="mailto:jeffrey.durrence@mcleanengineering.com" \
target="_blank" rel="nofollow noopener \
noreferrer">jeffrey.durrence@mcleanengineering.com</a><br> McLean Engineering \
Company<br> 815 South Main Street<br>
Moultrie, GA 31768<br>
<br>
</div>
</div>
</div>
</div>
<br>
<div style="margin:0px;padding:0px;font-family:monospace">_______________________________________________<br>
Qgis-user mailing list<br>
<a href="mailto:Qgis-user@lists.osgeo.org" rel="nofollow noopener \
noreferrer nofollow noopener noreferrer" \
target="_blank">Qgis-user@lists.osgeo.org</a><br> List info: <a \
href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noopener noreferrer \
nofollow noopener noreferrer nofollow noopener noreferrer" \
target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br> \
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" \
rel="noopener noreferrer nofollow noopener noreferrer nofollow noopener noreferrer" \
target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br> </div>
</blockquote>
<p><br>
</p>
<br>
</div>
</div>
</blockquote>
</div>
</blockquote></div><br></div></div></body></html>
[Attachment #6 (text/plain)]
_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic