Bug report #21227
Geopackage layer rename in DB Manager does not update f_table_name values in the layer_styles table or the Triggers
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: |  Martin Dobias | ||
| Category: | DB Manager | ||
| Affected QGIS version: | 3.4.4 | Regression?: | No |
| Operating System: | Windows 10 | Easy fix?: | No |
| Pull Request or Patch supplied: | Yes | Resolution: | fixed/implemented |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 29045 |
Description
We have a geopackage file with some layers and some styles for those layers, including default styles that display when we add the layers to the map canvas.
We use DB Manager to rename one or more of the geopackage layers.
For the renamed layers, the text in the Triggers section of the DB Manager Info tab still refers to the old layer name, and we cannot edit this (I do not know what consequences this may have).
In the layer_styles table for this geopackage, viewed in the Table tab of DB Manager, the values in the f_table_name still contain the old layer names. Consequently, the correct default styles do not display when we add the layers to the Map Canvas, and in Layer Properties, the Style > Load Style > from database (Geopackage) 'Database styles manager' dialog lists nothing under 'Styles related to the layer'.
We can find the appropriate style if we look for it in the list of 'Other styles on the database', but this is a overly complicated procedure to obtain the saved style, and it is not really something we can expect our novice-to-intermediate QGIS users to do every time.
Associated revisions
GPKG: Rename styles when layers are renamed
Partially fixes #21227
TODO:
- DB manager
- Other providers
[db-manager] Use QgsDataItem implementation for GPKG layer rename
- Removes code duplication
- Uses a tested and robust implementation (from OGR)
- Takes care of renaming QGIS styles
- Updates the information view in the plugin
Fixes #21227
[db manager] Rename layer style entry when renaming gpkg tables (fixes #21227)
This has been already fixed in master and backported to 3.6 using browser data items.
However the fix can't be directly backported to QGIS 3.4 because in 3.4 geopackage
data item does not support renaming.
History
#1
Updated by Steve Lowman about 5 years ago
I notice that there is a plugin called 'DB Style Manager', which is designed only for PostGIS connection, not for geopackages. Still, perhaps its code could help with resolving this issue for geopackages, if the resolution is not easy.
Also, I wonder whether this bug also extends to PostGIS connections? I have not yet been able to test for this, as I do not yet make regular use of PostGIS.
#2
Updated by Alessandro Pasotti about 5 years ago
- Assignee set to Alessandro Pasotti
#3
Updated by Alessandro Pasotti about 5 years ago
- Status changed from Open to In Progress
- Pull Request or Patch supplied changed from No to Yes
Ok for styles: I'm working on it on PR https://github.com/qgis/QGIS/pull/9164
About triggers: what triggers exactly are not updated?
The current implementation relies on GDAL which does update all geopackage related triggers, if you have custom triggers then they will not be updated and it's a won't fik (IMO).
#4
Updated by Steve Lowman about 5 years ago
- File DB Manager Rename bug - Triggers.png added
Thanks Alessandro. For the Triggers, there are two of them in these layers, both seem to be about feature count - one for "insert" and the other for "delete". I do not know what they really do.
I will attach an image to show these. I changed the layer name, but the previous layer name is still there for these insert and delete feature counts Triggers.
#5
Updated by Alessandro Pasotti about 5 years ago
Oh, I see, it's an issue in the dialog which is not updated, the triggers are acually updated correctly in the DB but the dialog is not.
#6
Updated by Alessandro Pasotti about 5 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
Applied in changeset qgis|61d361d6746e2e6d668616b70597f1c81bb5486d.
#7
Updated by Steve Lowman about 5 years ago
- Status changed from Closed to Reopened
It is fixed in 3.6, but not fixed in the upgraded 3.4.5 LTR.
#8
Updated by Alessandro Pasotti about 5 years ago
For the record: it was not fixed in 3.4 because the implementation is based on a feature which is only available in 3.6 hence a straight backport was unfortunately not feasible.
#9
Updated by Steve Lowman about 5 years ago
Is there any way to fix it in 3.4? It messes up our work flow quite badly.
#10
Updated by Alessandro Pasotti about 5 years ago
There are multiple ways, see this article (not written by me) http://nyalldawson.net/2016/08/how-to-effectively-get-things-changed-in-qgis/
#11
Updated by Steve Lowman about 5 years ago
Okay, thanks, I hope I am not being put into category 7. I just work here and have very little influence over anything, but I will make a suggestion. Meanwhile, I guess you had better close this report again.
#12
Updated by Alessandro Pasotti about 5 years ago
Thanks for your understanding: we have very limited time resources (not to mention the ridiculously slow budget) and we have to prioritize.
#13
Updated by Steve Lowman about 5 years ago
Would you be able to recommend who best to contact to get a price estimate for fixing this in the LTR, or should I just contact someone local on the list at https://www.qgis.org/en/site/forusers/commercial_support.html ?
#14
Updated by Alessandro Pasotti about 5 years ago
In that list you can find a lot of qualified free-lance developers and companies (included myself), feel free to contact anyone.
#15
Updated by Giovanni Manghi about 5 years ago
- Resolution set to fixed/implemented
- Status changed from Reopened to Closed
#16
Updated by Saber Razmjooei about 5 years ago
- Assignee changed from Alessandro Pasotti to Martin Dobias
- Status changed from Closed to Open
#17
Updated by Martin Dobias about 5 years ago
- Status changed from Open to Closed
Applied in changeset qgis|9eca4059b8d09aab9eac5995f899a9bd07cd0083.