Bug report #12266

Spatialite connection not correctly freed

Added by Hugo Mercier over 9 years ago. Updated over 6 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Data Provider/SpatiaLite
Affected QGIS version:2.8.0 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:not reproducable
Crashes QGIS or corrupts data:No Copied to github as #:20451

Description

The spatialite connection pool mechanism seems too conservative.
It fails with the following scenario :
  • load a vector layer out of a spatialite file t.sqlite
  • close it
  • remove t.sqlite on disk
  • recreate it with a different content (change table name)
  • try to open (another) vector layer from the same t.sqlite with qgis: will issue "no such table ..."

(An example test case to reproduce is attached)

It is due to the fact that the connection pool stays in memory and file name is used as connection id.

However, I guess this is the expected behaviour: the connection pool is here to avoid re-creation of connection.

One possibility would be to use a unique id of the sqlite filename for the connection pool, instead of the plain filename. We could use the creation date, but it is only precise to the second.

We could empty the connection pool at provider's destruction, but then there would be no point at using this connection pool ...

So, I guess this is a feature and not a bug : it's up to the caller to make sure the file used for the spatialite layer is not already known ?

test_connpool.py Magnifier (2.58 KB) Hugo Mercier, 2015-02-25 05:19 AM

History

#1 Updated by Giovanni Manghi over 7 years ago

  • Easy fix? set to No
  • Regression? set to No

#2 Updated by Regis Haubourg over 6 years ago

  • Status changed from Open to Feedback
  • Description updated (diff)

still true in release and ltr?

#3 Updated by Giovanni Manghi over 6 years ago

  • Resolution set to not reproducable
  • Status changed from Feedback to Closed

Closing for lack of feedback.

Also available in: Atom PDF