Bug report #20276
Off-Line editing: attributes are shifted when using GPKG as off-line format
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: |  David Signer | ||
| Category: | C++ plugins/Offline editing | ||
| Affected QGIS version: | 3.4.0 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | Yes | Copied to github as #: | 28097 |
Description
New description:
On the checkout - If I use Geopackage I get a "shift" of attributes. I have included a screenshot named Pre-Checkout.png . When I check out the data the attributes move one column to the right. I included a screenshot for postcheckout.png. If you look at the two screenshots - all the attributes have moved columns.
Old description:
I have a postgis database and the client is wanting to use the offline editing functionality. When I checkout a layer into a geopackage in 3.4 I noticed that there is a fid column added - but in adding the column it's shoving all the attribution over one column so the attribute no longer matches the column (for instance seg_side should contain either 'L' or 'R' and doesn't now).
If I take a layer offline into spatialite I'm having to manually fill out the primary key BUT the layer columns stay intact. Which manually filling out that is going to screw up the database on check-in.
I didn't try this in 3.2. I may try shortly if I get some time. So I have no idea if this is a regression or not.
I have attached a link to the original database in case something can be wrong there. It's a pd_dump and is 24mb so I've placed it in Dropbox: https://www.dropbox.com/s/67z5dn196497bev/hc911.backup?dl=0. It can be restored using psql -d <database> -f hc911.backup
Related issues
Associated revisions
leave last attribute empty instead of first
because though fid appears to be the first field it's added in the end and has the last index.
fixes #20276
handle fid attribute in attrLookup on synchronization
and use column++ again on iteration through attributes on copyVectorLayer
fixes #20276 especially the not reported issue with synchronization
leave last attribute empty instead of first
because though fid appears to be the first field it's added in the end and has the last index.
fixes #20276
(cherry-picked from d173b70b5335b93dbf049a3f40579fcb032dc8d6)
handle fid attribute in attrLookup on synchronization
and use column++ again on iteration through attributes on copyVectorLayer
fixes #20276 especially the not reported issue with synchronization
(cherry-picked from 0f653179ffcb73b5e9b4990592f759e4ea2d023f)
History
#1
Updated by Giovanni Manghi over 5 years ago
- Regression? changed from No to Yes
- Subject changed from Check out with QGIS against a postgis database. to Off-Line editing should NOT ask to fill manually the PK field
- Status changed from Open to Feedback
- Priority changed from Normal to High
- Operating System deleted (
Windows 10, Ubuntu 18.04) - Crashes QGIS or corrupts data changed from Yes to No
QGIS 2.18:
add a postgis layer
put it in off-line mode
edit it (add feature) > is NOT asked to fill (not mandatory) the field that represent the PK in pgsql
synchronize it back > all OK (the new feature is given a proper value for the PK field)
QGIS 3.4:
add a postgis layer
put it in off-line mode (spatialite or geopackage)
edit it (add feature) > the field that represent the PK is marked as mandatory and the user must fill it manually to be able to synchronize back. This of course can cause errors.
To the original issuer: I don't understand your description when using GPKG as format (I didn't tested your data because is not just a table, but it wants to restore a number of other things, like pgrouting). Here in my test if does indeed add a new field "fid", but in off line mode this is set as "autogenerate" and it does disappear when synchronizing back (and all the other columns are just ok).
#2
Updated by Randal Hale over 5 years ago
- File PostCheckout.png added
- File pre-checkout.png added
I should have described that better and not put two issues in one ticket. I'm sorry about that.
On the checkout - If I use Geopackage I get a "shift" of attributes. I have included a screenshot named Pre-Checkout.png . When I check out the data the attributes move one column to the right. I included a screenshot for postcheckout.png. If you look at the two screenshots - all the attributes have moved columns.
I didn't know pgrouting was included - I will attempt to see if this happens without anything included except the extension postgis.
#3
Updated by Giovanni Manghi over 5 years ago
- Crashes QGIS or corrupts data changed from No to Yes
- Regression? changed from Yes to No
- Status changed from Feedback to Open
- Description updated (diff)
- Subject changed from Off-Line editing should NOT ask to fill manually the PK field to Off-Line editing: attributes are shifted when using GPKG as off-line format
Randal Hale wrote:
I should have described that better and not put two issues in one ticket. I'm sorry about that.
On the checkout - If I use Geopackage I get a "shift" of attributes. I have included a screenshot named Pre-Checkout.png . When I check out the data the attributes move one column to the right. I included a screenshot for postcheckout.png. If you look at the two screenshots - all the attributes have moved columns.
ouch, that does not look good at all. I overlooked this problem. We should definitely split the ticket.
#4
Updated by Giovanni Manghi over 5 years ago
ouch, that does not look good at all. I overlooked this problem. We should definitely split the ticket.
see also #20301
#5
Updated by Jürgen Fischer over 5 years ago
- Related to Bug report #20301: Off-Line editing should NOT ask to fill manually the PK field added
#6
Updated by Jürgen Fischer over 5 years ago
- Description updated (diff)
#7
Updated by Randal Hale over 5 years ago
Also from Twitter this morning - #20040
#8
Updated by Chad Howard over 5 years ago
Has there been any movement on this topic. I'm working with Randy Hale on this and my 911 project is in standstill until we resolve this issue. Real excited that we have built this server and putting ArcGIS to bed but if I can't work this problem of checking the database out I have to revert back to Arc?
#9
Updated by Giovanni Manghi over 5 years ago
Chad Howard wrote:
Has there been any movement on this topic. I'm working with Randy Hale on this and my 911 project is in standstill until we resolve this issue. Real excited that we have built this server and putting ArcGIS to bed but if I can't work this problem of checking the database out I have to revert back to Arc?
this functionality seems to break at the worst possible moment also for me, said that if for you is a blocker then consider supporting the work necessary for the fix rather then waiting for the fix (as is not guaranteed it will be fixed soon).
#10
Updated by David Signer over 5 years ago
- Assignee set to David Signer
#11
Updated by Chad Howard over 5 years ago
Giovanni, I am an end user, not a programmer so I have no idea where to begin. Like I said I am new to GIS (last 3 years) and have only used ArcGIS and really love QGis and now that I've spent several thousand dollars to make a server i really don't want to go back to ArcGIS. I'm afraid I'm not going to be much help in this capacity. I may try this same thing tomorrow with the new Mac version of 3.4.1 and see if we get the same issue. Thanks for all you guys help Giovanni and David.
#12
Updated by David Signer over 5 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Applied in changeset qgis|d173b70b5335b93dbf049a3f40579fcb032dc8d6.