Multi-user edits corruputs data (was: Wrong vertex path after refreshing layer)

[FabioAzevedo0619]

Scenario: Two users in different machines, working with the same WFS endpoint.

Steps to reproduce:

1. User 1 loads layer x;
2. User 1 changes a feature geometry and saves it;
3. User 2 loads layer x;
4. User 2 changes the same feature that User 1 did and saves it;
5. User 1 refreshes layer x and now that feature has the previous vertex path despite the drawing being updated.

Windows 10 and Qgis 3.4.9

[gioman]

@FabioAzevedo0619 what is the wfs-t endpoint, qgis server? geoserver? other?

[FabioAzevedo0619]

@gioman geoserver.

[gioman]

geoserver

version?

@FabioAzevedo0619 and thee underlying datsource? postgis? other?

[FabioAzevedo0619]

@gioman the geoserver version is 2.15.2 and the urderlying datasource is postgis, version 2.4.10

[gioman]

I confirm the issue, in my case I used QGIS 3.8, one client on Windows and the other on Linux:

This is NOT limited to WFS-T layers, it also affects PostGIS layers (at least!) and it configures as a very bad regression/issue.

This ticket is labeled high priority because it leads to data loss/corruption.

[gioman]

Screencast that shows the issue:

[roya0045]

Did anyone check if it was a display issue only and if the data was properly modified in the provider?
From what I'm seeing two elements might be related to QGIS (either the POST or the display).
I doubt that the providers don't have issues with multiedit.
Otherwise could it also be possible that QGIS keep some information locally to prevent some overhead and that information would conflict with incoming information?

I remember doing tests in geopackage or some other local DB file and it seemed ok at the time, but it would need to be retested.

[FabioAzevedo0619]

@roya0045 when we ran into this problem, we checked, and the data was properly modified in the provider.

[FabioAzevedo0619]

It seems that modifying the geometry and undoing it after, makes the vertices align with the geometry drawing.

[gioman]

Did anyone check if it was a display issue only and if the data was properly modified in the provider?

the subject of this ticket could be misleading, the scenario is not the one where two users toggle edits on the same feature at the same time and modify it. In this case, the last one who presses save "wins".

what we are observing here is different:

a saved edit by a user is completely "ignored" by the edit tool of the other user, regardless if the second user refreshes the map (after refreshing the edits by the first user these are clearly visible in the canvas of the second user).

[roya0045]

Did anyone check if it was a display issue only and if the data was properly modified in the provider?

the subject of this ticket could be misleading, the scenario is not the one where two users toggle edits on the same feature at the same time and modify it. In this case, the last one who presses save "wins".

what we are observing here is different:

a saved edit by a user is completely "ignored" by the edit tool of the other layer, regardless if the second user refresh the map (after refreshing the edits by the first user are clearly visible in the canvas).

Without being too familiar with that area of the code, I would assume that in order to solve this we would need to alter the cache validation/invalidation and trigger it when editing/refreshing.

[gioman]

Just to be sure I checked this scenario on 2.18 and was NOT a problem there.

[troopa81]

It's quite the same problem than #40720 but for WFS instead of PostGIS.

The thing is that snapping index is not up to date, because snapping index takes time to build and we can't rebuild every time we render (more details in #40720 (comment) )

So we need a way to be informed that data has changed. With PostGIS, there is notify. I don't know much WFS provider but if it's possible with one way or another to detect a layer data change, then we just have to fire dataChanged and index will be rebuilt, and this issue fixed.

[uclaros]

So we need a way to be informed that data has changed. With PostGIS, there is notify.

This solution is a hack. We can't rely on a provider specific feature (notify) that needs setting up just to enable reliable multi-user editing. What we actually need is closer to what you propose on the other thread, a fast way of updating the index instead of rebuilding it. We could have some kind of fast geometry inequality logic in order to only update modified geometries.

[troopa81]

@uclaros I'm afraid that testing if some geometries have been modified in your dataset every time you render your layers will slow down considerably rendering. What I propose on the other thread is to speed up and improve indexing so users doesn't have to wait for snapping for long on large dataset, but it won't be able to fix this issue.

We could have some kind of fast geometry inequality logic

Are you thinking of something ?

[roya0045]

Would it be possible to validate geometries that are rendered only or near the pointer?

[troopa81]

Would it be possible to validate geometries that are rendered only or near the pointer?

What do you mean by validate? You need to build the index (which take time) to find the geometry around your pointer.

[roya0045]

Yes but once the index is build you can use it to query the source and perform validation. I'm assuming it would be possible to update the index of the geometries which don't match anymore. I doubt the index is a single blob that must be recreated in its entirety for any minor changes.

[troopa81]

I'm assuming it would be possible to update the index of the geometries which don't match anymore.

Yes, it's possible, and it's done when a geometry is modified. But the question is "How do you detect if a geometry has been modified without any provider specific notification?", you'll have to go through all you geometry and compare with the one in the index, which IMHO will take too much time to be done on regular basis (every time we render)

[roya0045]

Would hashing be viable to detect initiale changes? Maybe features could be grouped and then hashed.

[troopa81]

Would hashing be viable to detect initiale changes?

Maybe. I'm still not sure it would not take too much time to compute and compare hash