Bug report #20276

Off-Line editing: attributes are shifted when using GPKG as off-line format

Added by Randal Hale almost 2 years ago. Updated almost 2 years ago.

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.

#20276-2

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

PostCheckout.png - After using offline editing (92.9 KB) Randal Hale, 2018-10-31 12:39 PM

pre-checkout.png - Before using offline editing. (95.3 KB) Randal Hale, 2018-10-31 12:39 PM


Related issues

Related to QGIS Application - Bug report #20301: Off-Line editing should NOT ask to fill manually the PK f... Open 2018-10-31

Associated revisions

Revision d173b70b
Added by David Signer almost 2 years ago

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

Revision 0f653179
Added by David Signer almost 2 years ago

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

Revision bec04c1e
Added by Matthias Kuhn almost 2 years ago

Merge pull request #8600 from signedav/fix_gpkg_order

Offline editing to GPKG attribute order. Fixes #20276

Revision 20ea3d6d
Added by David Signer almost 2 years ago

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)

Revision e1c4419b
Added by David Signer almost 2 years ago

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 almost 2 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 almost 2 years ago

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 almost 2 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 almost 2 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 almost 2 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 almost 2 years ago

  • Description updated (diff)

#7 Updated by Randal Hale almost 2 years ago

Also from Twitter this morning - #20040

#8 Updated by Chad Howard almost 2 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 almost 2 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 almost 2 years ago

  • Assignee set to David Signer

#11 Updated by Chad Howard almost 2 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 almost 2 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF