[QGIS-Developer] Vertex tool and cache invalidation

Hugo Mercier hugo.mercier at oslandia.com
Thu Jan 24 01:49:38 PST 2019


Hi Martin,

On 23/01/2019 23:02, Martin Dobias wrote:
> Hi Hugo
> 
> (finally coming back to the earlier thread now)
> 
> On Mon, Jan 7, 2019 at 4:14 PM Hugo Mercier <hugo.mercier at oslandia.com> wrote:
>>>
>>> Are the issues you mentioned solved now by your PR
>>> https://github.com/qgis/QGIS/pull/8724 or that was some other separate
>>> issue?
>>
>> Unfortunately, this only solves a very small part of the problem. The
>> overall issue of wrong cache synchronization is still there.
> 
> So what are the missing pieces of the puzzle? With data dependencies
> defined in QGIS, I would expect that edit of a geometry in a layer
> should trigger dataChanged() signal, so any piece of QGIS that caches
> any data is notified that caches should be invalidated... isn't this
> the case?

It is, but snapping invalidation of indexes for a whole layer can take a
lot of time to rebuild, depending on the indexing strategy.

So the initial benefit of building an index once and querying it with
good performances afterwards is partly lost.

As discussed in a PR (https://github.com/qgis/QGIS/pull/8862), we have
to find a way to speed up this index rebuilt to have an acceptable solution.

Moreover, it requires the user to declare dependencies between layers.

> 
> 
>>> For your open question with "click first" behavior of vertex tool as
>>> an option - I don't know. There has been some interest to address some
>>> ergonomic issues in the new implementation, but I am not sure yet what
>>> we would end up doing...
>>
>> I understand. I am still looking for a solution here.
>>
>> So instead of resurrecting the old vertex tool, would it be possible to
>> make it work without index/cache ?
>> I understand a cache has been introduced to allow for edition when lots
>> of geometries are displayed on the current extent. But usually geometry
>> editions are made at a high level of details, when a few geometry
>> features are visible. Is a cache still needed if we somehow enforce the
>> edition to be allowed only at small scale ?
> 
> I am not sure I understand what is the problem with cache... attribute
> table has its cache, vector joins have caches, snapping has its cache,
> so vertex tool has its cache too to make things faster. As long as we
> can detect that the cache needs to be invalidated, there should not be
> a problem. Could you please shed some light where is the source of the
> troubles you are having?

I am sure you know the quote "There are two hard things in computer
science: cache invalidation, naming things, and off-by-one errors." :-)

Caches are very nice until we find a situation where it gets complicated
to know what and when to invalidate.

So there are 3 general approaches I can see for the problem I have:
- avoid cache : the less intrusive one for the user, provided we
maintain good performances
- invalidate the whole layer at each edition: see above
- invalidate precisely at the level of each feature: should be signaled
by the data provider but seems (on first thought) hard to auto-detect,
so would require a lot of work by the user

Hugo


More information about the QGIS-Developer mailing list