Bug report #8908
spatialite database updated only from opening qgis project
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Data Provider/SpatiaLite | ||
| Affected QGIS version: | 2.0.1 | Regression?: | No |
| Operating System: | ubuntu / win | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | end of life |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 17584 |
Description
If I load a spatialite spatial view into QGIS (2.x) with no data in it, then the spatialite database gets updated only from adding that layer.
The same thing happens each time I open a qgis project with an empty spatialite spatial view.
I guess this has to do with the layer statistics being updated (the extents for the spatial view I think).
This is a problem when using splite databases for offline work: Whenever a qgis project is opened, that includes an empty spatial view, then the database is updated - this triggers erroneous synchronisations when online again.
Marked as blocker since it is a regression from 1.8.
History
#1
Updated by Josef Källgården about 11 years ago
- File testdb.sqlite.zip added
Attached sample database. The database will be updated as soon as the view4 is added as a layer to a qgis project.
I think it is related to the null values in views_geometry_columns_statistics.
#2
Updated by aperi2007 - about 11 years ago
I guess to better understand the question and why it do this is preferrable to link the discussion on spatialite ML about it and the Furieri response.
https://groups.google.com/forum/#!topic/spatialite-users/6PW_iICSEG8
A.
#3
Updated by Josef Källgården about 11 years ago
As Furieri explains in the discussion on spatalite ML it is the optimistic approach (GAIA_VECTORS_LIST_OPTIMISTIC) of the qgs data provider that makes a spatialite db not being updated when a spatialite view is added to qgis. But as explained in the description above, whenever a spatialite view is empty, the db gets updated. I think this is an inconsistent behaviour.
Even though I would prefer that the db were not updated unless actual changes were made (easier when synching after offline use), I would very much prefer the behaviour to be consistent no matter if the view is empty or not. I can think of a few alternatives, but there are probably others:
a. stay with optimistic approach and fix a consistent behaviour by introducing some clever code in data provider to never update db unless time stamps say underlaying tables are updated
b. change to pessimistic approach
c. do nothing and stay with this inconsistency (I hope not)
#4
Updated by Matthias Kuhn almost 11 years ago
- Priority changed from Severe/Regression to Normal
#5
Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#6
Updated by Giovanni Manghi over 6 years ago
- Status changed from Open to Feedback
Please test with a recent QGIS release (2.18 or 3), if the issue/request is still valid change the affected version accordingly, if is fixed/implemented then close the ticket. Thanks!
#7
Updated by Josef Källgården over 6 years ago
- Status changed from Feedback to Open
Giovanni Manghi wrote:
Please test with a recent QGIS release (2.18 or 3), if the issue/request is still valid change the affected version accordingly, if is fixed/implemented then close the ticket. Thanks!
Confirmed this issue still exists for qgis version 2.18.16 (For some reason I can not change affected version in the original bug report above.)
#8
Updated by Giovanni Manghi over 5 years ago
- Resolution set to end of life
- Status changed from Open to Closed
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/
QGIS 3.4 has recently become our new Long Term Release (LTR) version. This is a major step in our history – a long term release version based on the massive updates, library upgrades and improvements that we carried out in the course of the 2.x to 3x upgrade cycle.
We strongly encourage all users who are currently using QGIS 2.18 LTR as their preferred QGIS release to migrate to QGIS 3.4. This new LTR version will receive regular bugfixes for at least one year. It also includes hundreds of new functions, usability improvements, bugfixes, and other goodies. See the relevant changelogs for a good sampling of all the new features that have gone into version 3.4
Most plugins have been either migrated or incorporated into the core QGIS code base.
We strongly discourage the continued use of QGIS 2.18 LTR as it is now officially unsupported, which means we’ll not provide any bug fix releases for it.
You should also note that we intend to close all bug tickets referring to the now obsolete LTR version. Original reporters will receive a notification of the ticket closure and are encouraged to check whether the issue persists in the new LTR, in which case they should reopen the ticket.
If you would like to better understand the QGIS release roadmap, check out our roadmap page! It outlines the schedule for upcoming releases and will help you plan your deployment of QGIS into an operational environment.
The development of QGIS 3.4 LTR has been made possible by the work of hundreds of volunteers, by the investments of companies, professionals, and administrations, and by continuous donations and financial support from many of you. We sincerely thank you all and encourage you to collaborate and support the project even more, for the long term improvement and sustainability of the QGIS project.