Bug report #14799
'Create transaction groups automatically whenever possible (Experimental)' issues
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: |  Matthias Kuhn | ||
| Category: | Vectors | ||
| Affected QGIS version: | 2.14.2 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | end of life |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 22756 |
Description
After enabeling 'Create transaction groups automatically whenever possible (Experimental)' in Settings/Options.../Data Sources some icons ('Save Layer Edits', 'Undo', 'Redo') are not available and 'Show Feature Count' is not working properly for categorized layers.
Associated revisions
[FEATURE] Add undo and redo on transaction groups (#4765)
- [FEATURE] adds undo/redo for transaction groups
[needs-docs] the undo/redo now works with transcation groups. Just check
that there is no restriction in the transaction groups doc concerning
undo.
related to #14799
The undo/redo is implemented using SAVEPOINT.
The QgsTransaction interface has been enlarged to allow savepoints
creation and management. The savepoint is destroyed on
rollbackToSavepoint to have the same behavior has the sql ROLLBACK TO
SAVEPPOINT.
To avoid the creation of a savepoint for each feature modified in bulk
editing (e.g. paste, field calculator) the logic is a bit complicated: the
savepoint is created on QgsVectorLayer::editCommandStarted and the first
actual undo command (QgsVectorLayerUndoPassthroughCommand) is
responsible for the re-creation of the savepoint in case of undo-redo.
Since the behavior must be different in case edition doesn't take place
inside an edit command, a member function has been added to
QgsVectorLayer to expose the mEditCommandActive state.
Another (commented) tricky bit is the modification of the database
structure on add/delete attributes. On undo, the attribute is removed
before the rollback to savepoint, i.e. there is a useless ALTER TABLE
issued to restore the structure just before restoring it with the
ROLLBACK TO SAVEPOINT. This is necessary to make the provider
aware of the change of structure. It could be nicer/cleaner to have a way
to reload providers metadata.
The editPaste function has also been modified to use addFeatures instead of
addFeature (plural/singular), this is at the expense of an additional "cpy"
of the clipboard in memory, but it should improve perf with postgis provider.
- fixup operator aliases
History
#1
Updated by R. R. almost 8 years ago
- File 14799.mp4 added
#2
Updated by Regis Haubourg over 7 years ago
- Assignee set to Matthias Kuhn
- Priority changed from Normal to High
Hi, confirmed here with 2.16.3
Matthias, do you confirm?
#3
Updated by Matthias Kuhn over 7 years ago
- Status changed from Open to Feedback
Can you confirm all of them?
The feature count and save button as seen in the video are bugs.
Undo and Redo are not available because the edit log is on the database server and not on inside QGIS. This was an expected effect when implementing transactions.
It should be possible to get some degree of undo/redo with postgres save points but that will be a new feature request.
#4
Updated by Giovanni Manghi over 7 years ago
- Status changed from Feedback to Open
- Priority changed from High to Normal
- Category set to Vectors
#5
Updated by Giovanni Manghi almost 7 years ago
- Regression? set to No
- Easy fix? set to No
#6
Updated by Regis Haubourg over 6 years ago
Matthias Kuhn wrote:
Can you confirm all of them?
The feature count and save button as seen in the video are bugs.Undo and Redo are not available because the edit log is on the database server and not on inside QGIS. This was an expected effect when implementing transactions.
It should be possible to get some degree of undo/redo with postgres save points but that will be a new feature request.
Undo Redo is now back on master :)
#7
Updated by Giovanni Manghi about 5 years ago
- Status changed from Open to Closed
- Resolution set to end of life
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.