Feature request #9471
attribute table isn't refreshed after save
| Status: | Open | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: |  Matthias Kuhn | ||
| Category: | Unknown | ||
| Pull Request or Patch supplied: | No | Resolution: | |
| Easy fix?: | No | Copied to github as #: | 18063 |
Description
This is an issue when you have underlying triggers that will change the table when you save your modifications.
The only workaround is to close and reopen the table.
The refresh can be used to fix #1659
History
#1
Updated by Matthias Kuhn almost 11 years ago
- Assignee set to Matthias Kuhn
Hi Vincent,
Is this an issue in both, 2.0.1 and master? I have just yesterday been working on auto-updates (so be sure to test with latest master) to the table and wrote a mail [1] to the dev-ml yesterday which could very likely be related to this issue.
If this is a plugin of yours, make sure, that
- Changes are written to the layer and not the dataprovider directly.
- Changes are made wrapped in beginEditCommand() / endEditCommand()
If the second point fixes this issue for you, can you please give me a short notice. That would be the answer to my mail [1] and could easily be fixed.
PS: I will be away for the next week. If you find anything concerning this, can you write me a PM, so I don't forget about this when I get back. Thank you.
[1] http://lists.osgeo.org/pipermail/qgis-developer/2014-January/030694.html
#2
Updated by Vincent Mora almost 11 years ago
- File test_9471.qgs added
- File test_9471.sqlite added
Hi Matthias,
Is this an issue in both, 2.0.1 and master? I have just yesterday been working on auto-updates (so be sure to test with latest master) to the table and wrote a mail [1] to the dev-ml yesterday which could very likely be related to this issue.
I'm working on master (I did not check for 2.0.1). Thanks for pointing your mail on the ML, as far as I understand it's related to this issue.
If this is a plugin of yours, make sure, that
Nope, it's not a plugin. I have a spatialite trigger that removes a feature when a related feature is removed. I use the attribute table to do the removal, but the feature that is deleted by the trigger when I save still appears in the table, I have to close and reopen to have an updated view (i.e. for the feature deleted by the trigger to disappear).
I tested this morning with the latest master, an the problem is still there (are you referring to commit d378f942a50 in you mail on the ML ?).
I join a simple test, if you open the attribute table and delete one feature, both are delete by a spatialite trigger.
#3
Updated by Matthias Kuhn almost 11 years ago
There is currently no possibility for a provider to push change-notifications back to QGIS. We would need a new API for push-notifications from providers in QGIS itself and most likely also a plugin for backends to push these notifications to the QGIS providers. The implementation mentioned in my last post only referred to changes made from inside QGIS.
I am not convinced that a automatic reload after save is the right thing to do. It can introduce a rather big overhead and is likely to actually miss events (e.g. a trigger updating a different layer). Instead I would prefer to have abovementioned support for push-notifications or as an easier short-term solution an optional switch to toggle this behaviour. Maybe it would also be feasible to implement this kind of thing in a plugin (similar to this but including some way to also force the attribute table to be reloaded)
#4
Updated by Vincent Mora almost 11 years ago
- Tracker changed from Bug report to Feature request
It can introduce a rather big overhead and is likely to actually miss events (e.g. a trigger updating a different layer)
Isn't qgis reloading geometries every time you pan/zoom/refresh, it also reload data if you close/open the attribute table ?
But you're right, it will miss events.
What about a Refresh button, the same as in the main window, in the attribute table for a short an easier term solution?
I experimented with QgsAttributeTableModel::reload(const QModelIndex &index1, const QModelIndex &index2 ) (by calling that after save) but with no effect, is there a cache to dirty or something else ?
Anyway, I changed the status from Bug to Feature request.
#5
Updated by Matthias Kuhn almost 11 years ago
did you try to call QgsAttributeTableModel::loadLayer() ? I reckon that should refresh the cache as well.
A refresh button would be an acceptable solution I think.
#6
Updated by Antonio Locandro over 10 years ago
Wouldn't it be possible that upon toggling editing the attribute table would refresh itself without the need for a refresh button or close/open again?
#7
Updated by Antonio Locandro over 10 years ago
Adding again to this, the desired behaviour would be once you click stop editing, after committing changes QGIS would automatically refresh the table, there is no reason why I should press refresh to do that when the software can do it for me, it's an extra click that if you multiply for several hundreds of edits equals a lot of wasted time
#8
Updated by Matthias Kuhn over 10 years ago
There are IMO two reasons why the approach is wrong:
- The loading will take place regardless if it's necessary. If there are no triggers (and that's not uncommon) or only unrelated columns are edited it introduces a lot of "wasted time" as well.
- Data may be changed from outside. (E.g. from a plugin without toggling the layer's edit state by accessing layer.dataProvider() directly). In that case the table ought to be reloaded but isn't.
Therefore, the proposed trigger event (save layer) is not adequate and leads do performance degradation in many cases.
What could be discussed is a layer option that needs to be manually turned on (or if there is a good indicator for auto-detection, that's fine as well of course).
#9
Updated by Giovanni Manghi over 7 years ago
- Easy fix? set to No
#10
Updated by Jürgen Fischer about 7 years ago
- Category set to Unknown