Bug report #10537

Converting offline twice within the same instance causing unusable offline state

Added by Drew Nix over 10 years ago. Updated over 8 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:Alessandro Pasotti
Category:C++ plugins/Offline editing
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:Yes Copied to github as #:18945

Description

Problem Description:
Converting offline twice within the same running project instance causes unusable offline state.

Problem Result:
After which the "Convert to Offline Project" is grayed out. The project will no longer synchronize and the project is stuck in an Offline State.

If the project is saved, upon opening the same scenario applies.

The only fix to this is to open the project file in a text editor and delete the offline information and save the file. This is impossible for most of our users.

Steps to reproduce:
Open Qgis
Add PostGIS vector layer
Database > Offline Editing > Convert to Offline Project
Offline data: C:/OSGEO4W/bin/offline.sqlite
Select PostGIS vector layer
Database > Offline Editing > Syncronize
Database > Offline Editing > Convert to Offline Project
Offline data: C:/OSGEO4W/bin/offline.sqlite (Same dataset)

Errors:
table 'tog_indices' already exists
table 'log_layer_ids' already exists
table 'log_fids' already exists
table 'log_added_attrs' already exists
table 'log_added_features' already exists
table 'log_removed_features' already exists
table 'log_feature_updates' already exists
table 'log_geometry_updates' already exists

table '<PostGIS_LAYER>' already exists

Associated revisions

Revision f045492e
Added by Alessandro Pasotti over 8 years ago

[bugfix] offline editing converting offline twice

Fixes #10537: Converting offline twice within the same
instance causing unusable offline state.

The problem was due to spatialite connection not being
invalidated. When the new offline layer is re-created
the provider connection doesn't pick the latest commits.

Funded by Boundless

Revision fa9862b2
Added by Alessandro Pasotti over 8 years ago

[bugfix] offline editing converting offline twice

Fixes #10537: Converting offline twice within the same
instance causing unusable offline state.

The problem was due to spatialite connection not being
invalidated. When the new offline layer is re-created
the provider connection doesn't pick the latest commits.

Funded by Boundless

(cherry-picked from f045492)

History

#1 Updated by Giovanni Manghi over 10 years ago

  • Operating System deleted (Windows 7 )
  • OS version deleted (64 bit)

On Linux I can't confirm the error messages and the offline db in a unusable state, but I can confirm that overwriting an already existing offline db with a new one causes strange things to happen (the most obvious is the loss of features). If each time layer(s) are placed off-line is used a new offline db (no overwriting) then things are ok.

#2 Updated by Jürgen Fischer over 10 years ago

  • Category set to C++ Plugins

#3 Updated by Jürgen Fischer over 10 years ago

  • Target version changed from Version 2.4 to Future Release - High Priority

#4 Updated by Jürgen Fischer over 10 years ago

  • Category changed from C++ Plugins to C++ plugins/Offline editing

#5 Updated by Jürgen Fischer about 10 years ago

  • Subject changed from Offline Editing - Converting offline twice within the same instance causing unusable offline state to Converting offline twice within the same instance causing unusable offline state

#6 Updated by Giovanni Manghi about 10 years ago

  • Priority changed from High to Severe/Regression
  • Target version changed from Future Release - High Priority to Version 2.6

found that this is a regression since qgis 2.0.1, where overwriting the already existing offline db worked without issues.

Moreover now on QGIS master on Linux it causes a crash

Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Warning: Object::disconnect: Unexpected null parameter
Fatal: ASSERT failure in QList<T>::at: "index out of range", file /usr/include/qt4/QtCore/qlist.h, line 469
QGIS died on signal -1Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
No thread selected
No stack.
gdb returned 0
Aborted

#7 Updated by Jürgen Fischer about 10 years ago

  • Target version changed from Version 2.6 to Future Release - High Priority

#8 Updated by Matthias Kuhn over 9 years ago

  • Status changed from Open to Feedback
  • Concerning the crash, which operation have you been performing?
  • We could delete the offline db after going online. Or rename it to a backup copy which will eventually be overwritten on the next sync. That way one would always have a backup copy. Although I am not sure if it will be that easy to recover information from it.
  • When going offline and the target file already exists, I think a warning should be raised, asking for confirmation if it's ok to overwrite.
    • In the future this should possibly be enhanced with a recovery option to synchronized leftover data in not-yet (fully) synchronized offline databases.

Comments?

#9 Updated by Giovanni Manghi over 9 years ago

  • Status changed from Feedback to Open

Matthias Kuhn wrote:

  • Concerning the crash, which operation have you been performing?

nothing special, adding/editing one feature.

  • We could delete the offline db after going online. Or rename it to a backup copy which will eventually be overwritten on the next sync. That way one would always have a backup copy. Although I am not sure if it will be that easy to recover information from it.
  • When going offline and the target file already exists, I think a warning should be raised, asking for confirmation if it's ok to overwrite.
  • In the future this should possibly be enhanced with a recovery option to synchronized leftover data in not-yet (fully) synchronized offline databases.

Comments?

it seems to me a good plan :)

#10 Updated by Drew Nix over 9 years ago

What about a fail-back as well (to a proper online state) if converting offline fails?

-- happy to see some activity here ;)

#11 Updated by Alessandro Pasotti over 8 years ago

  • Assignee set to Alessandro Pasotti

#12 Updated by Anonymous over 8 years ago

  • Status changed from Open to Closed

Also available in: Atom PDF