Bug report #12266

Updated by Regis Haubourg over 6 years ago

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 ?

Back