QGIS » QGIS Application

I very much agree !

The fact that layers which are currently unavailable are deleted upon opening a project is a big annoyance : what if the layer is on a (currently) unavailable network drive ?

Correcting this would also be the perfect occasion to add a "relink" action to the context menu and the layer properties, which would allow to change the source of a layer without changing anything else.

Oliver, you are talking about #8718
It's a different issue and it isn't strictly dependant on this one (although both of them could be solved by a redesign of bad layer handling).
Olivier Dalang wrote:

I very much agree !

The fact that layers which are currently unavailable are deleted upon opening a project is a big annoyance : what if the layer is on a (currently) unavailable network drive ?

Correcting this would also be the perfect occasion to add a "relink" action to the context menu and the layer properties, which would allow to change the source of a layer without changing anything else.

Hi !

It seems this has been done for 2.2 already...

But IMO, the current behavior is not satisfying, and even DANGEROUS !

Simple scenario : I open a huge project, and go take a nap while it loads. I come back, and don't see the message in the bar, which not only is quite subtle, but also vanishes after a few seconds. I work happily on my project, and save. BAM ! I just lost some layers with no way to recover them !

Currently, I would flag this as blocker, since it leads easily to data corruption.

Either we must move back to previous solution, or implement #8718

Can we flag this as a blocker ? (I almost lost some layers again)
Or is it happening only to me ?

Agreed with Olivier, we should mark this as a blocker until we have a behaviour that do not allow layer destruction unless user really wants it.
I suggest we keep bad layers in layer registry, with a flag for it like ESRI does (refactoring is under work, why not add this to the list). We should be able to correct bad layers on project opening OR a posterio in layer properties.
Cheers,
R2gis

+1 for flagging this as a blocker.

Nathan Woodrow wrote:

Is your data in PostGIS by any chance?

Hi ! Yes it seems to happen with PostGIS layers, not with shapefiles... I didn't test with other providers yet.

Martin wrote:

I don't think there is a scope to get this into 2.4 - I would classify this as a new feature since it would require non-trivial changes to the code. I agree the current behaviour is not nice, but I can't see a reason why it should be suddenly a blocker (the loading worked liked this for ages).

Getting a good solution to this problem (ie be able to load bad layer) is indeed not trivial, and there's already a feature request for this : #8718
But displaying the handle bad layer dialog instead of having the temporary message in the message bar shouldn't be hard ?

About the blocker flag, it's up to you, but I thought bugs leading to potential data loss (here : loss of layers) should be flagged as blockers.

Olivier Dalang wrote:

Nathan Woodrow wrote:

Is your data in PostGIS by any chance?

Hi ! Yes it seems to happen with PostGIS layers, not with shapefiles... I didn't test with other providers yet.

Ok now I understand what is going on - the "handle bad layers" dialog is available only for OGR, spatialite and delimitedtext layers. Other data sources are considered as "not fixable" because the dialog is only able to handle file-based sources.

We could at least easily remove the timeout of the message in the message bar, so it does not happen that you miss that information.

I was just going to change it so that non file based layers could just be hand edited. A lot of times it's just the connection string that needs to be updated. Shouldn't be too hard to do if you want me to take a look.