Bug report #21227

Geopackage layer rename in DB Manager does not update f_table_name values in the layer_styles table or the Triggers

Added by Steve Lowman over 1 year ago. Updated about 1 year ago.

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.

DB Manager Rename bug - Triggers.png - Image of DB Manager, showing two triggers where the layer name has not changed after layer rename. (58.9 KB) Steve Lowman, 2019-02-13 10:51 AM

Associated revisions

Revision 61d361d6
Added by Alessandro Pasotti over 1 year ago

GPKG: Rename styles when layers are renamed

Partially fixes #21227

TODO:

- DB manager
- Other providers

Revision 8639bcf8
Added by Alessandro Pasotti over 1 year ago

[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

Revision 9eca4059
Added by Martin Dobias about 1 year ago

[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 over 1 year 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 over 1 year ago

  • Assignee set to Alessandro Pasotti

#3 Updated by Alessandro Pasotti over 1 year 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 over 1 year ago

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 over 1 year 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 over 1 year ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

#7 Updated by Steve Lowman over 1 year 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 over 1 year 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 over 1 year ago

Is there any way to fix it in 3.4? It messes up our work flow quite badly.

#10 Updated by Alessandro Pasotti over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year 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 over 1 year ago

  • Resolution set to fixed/implemented
  • Status changed from Reopened to Closed

#16 Updated by Saber Razmjooei over 1 year ago

  • Assignee changed from Alessandro Pasotti to Martin Dobias
  • Status changed from Closed to Open

#17 Updated by Martin Dobias about 1 year ago

  • Status changed from Open to Closed

Also available in: Atom PDF