Bug report #2487
Memory data provider should not be saved
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 13 years ago
- Target version changed from Version 1.7.0 to Version 1.7.4
#2 Updated by Paolo Cavallini over 12 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 12 years ago
- Target version changed from Version 1.8.0 to Version 2.0.0
#4 Updated by Radim Blazek over 10 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 10 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 10 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.
- 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 10 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 7 years ago
- Easy fix? set to No
- Regression? set to No
#9 Updated by Giovanni Manghi over 5 years ago
- Status changed from Open to Closed
- Resolution set to end of life
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/