Bug report #2487

Memory data provider should not be saved

Added by Chris Crook over 9 years ago. Updated 6 months ago.

Status:Closed
Priority:Low
Assignee:-
Category:Project Loading/Saving
Affected QGIS version:master Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:12547

Description

Layers built with the memory data provider should not be saved to the project file, as when the file is reloaded, the data for the layers is no longer available. This means that reloading the project does not restore it to its saved state.

I think that when Quantum saves a project then it should check for in memory layers, and provide the option of saving them to a persistent provider, or removing them from the project.

Also it would good when an in memory layer is saved to a shapefile (or other persistent provider) from the legend right click menu if the layer was replaced with the saved layer. This make it much easier to make in memory layers persistent in the project. At the moment I think you need to save the layer, then load the saved version, and then remove the in memory layer.

History

#1 Updated by Giovanni Manghi almost 8 years ago

  • Target version changed from Version 1.7.0 to Version 1.7.4

#2 Updated by Paolo Cavallini over 7 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0
  • Affected QGIS version set to master
  • Crashes QGIS or corrupts data set to No

#3 Updated by Paolo Cavallini about 7 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#4 Updated by Radim Blazek over 5 years ago

  • Pull Request or Patch supplied set to No
  • Target version changed from Version 2.0.0 to Future Release - Nice to have
  • Assignee deleted (nobody -)

There are cases when saving memory layers (without data) in project is useful, for example if layer symbology has to be customized by user but layer data are always refreshed by plugin.

There are three possibilities to handle memory layers and all make sense in some situations:
  • write memory layer to project without data
  • write memory layer to project including data
  • don't write memory layer to project

It could be specified by new URI parameter but I am worried that it could be confusing for users.

#5 Updated by Chris Crook over 5 years ago

Interesting point .. I'm not convinced about the last case (don't write layer to project). My feeling is that the if a user closes and reopens a project then nothing should change, certainly not without a warning. It is hard to think of a case when the user would want the layer preserved (unless they are abandoning the changes and not saving the project) - after all if they don't want the layer then they will delete it in QGIS, not expect it to magically disappear when they save the project and reopen it.

At the moment this is implemented in the (non core) Memory Layer Saver plugin, which does include the option of not saving the layer (a plugin can set a layer property to tell the memory layer saver not to save the data).

The current implementation saves the data in a portable binary stream format provided by the Qt framework in a file that sits next to the project file.

I've found the plugin actually works very well as an approach - I no longer have to think about memory layers going away. If I was going to do anything with it now my inclination would be to put it into core, and perhaps port to C++ to remove the python dependency...

#6 Updated by Regis Haubourg over 5 years ago

+1 with Chris, Memory Layer Saver plugin is installed in default config here and IMHO should be ported to core.
It is easy to delete layers not needed, so I vote to keep persistent memory layers. But if on project loading, memory layer appears to be empty (no data coming), we should propose to suppress them in "handle bad layers" dialog.

Anyway, having a separate file for data is confusing for users here. Other possibilities have been explored in an old thread on the list:
  • change qgs file to a zip container and hide ressources (QGS xml, + data + fonts, + svg symbols in it) > quite a big change!
  • embed some data inside qgs > easy evolution, but weakens QGS fiel stability (if datastream Output fails, QGS is lost)
  • use sqlite container instead of a zip container > discarded because of sqlite dependencies

régis

#7 Updated by Radim Blazek over 5 years ago

regis Haubourg wrote:

It is easy to delete layers not needed, so I vote to keep persistent memory layers. But if on project loading, memory layer appears to be empty (no data coming), we should propose to suppress them in "handle bad layers" dialog.

Please keep also the possibility to don't save layer data if needed (specified by URI param?).

#8 Updated by Giovanni Manghi over 2 years ago

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

#9 Updated by Giovanni Manghi 6 months ago

  • Status changed from Open to Closed
  • Resolution set to end of life

Also available in: Atom PDF