[Qgis-developer] Merging of incompatible changes

[Martin Dobias]

On Thu, Oct 25, 2012 at 9:25 AM, Matthias Kuhn <matthias.kuhn at gmx.ch> wrote:
> Hi all,
>
> I don't know if somebody already brought up this (the discussion is
> already rather long), but is there no possibility for including legacy
> methods?
>
> For the iterators this would probably mean, that there is a reserved
> iterator running single-threaded for any calls to the old API.
>
> I don't know what would be necessary to make a legacy string API.

In my GSoC 2010 work I have done exactly that thing: support old API
backed by the new iterators. But it has proved to cause trouble when
combined with locking - imagine this case:
1. a function calls layer.select(). The old API support will
initialize an iterator and acquire a lock.
2. the function reads just one feature, then exits. Lock is still
acquired by old API support, because it is not possible to tell
whether some more features won't be fetched. If the function would
3. user triggers redraw of the canvas
4. renderer tries to acquire the lock... but it's still being held by
old API support, so the rendering thread has to wait... indefinitely

Normally if a function reads all data served from layer.select() that
would be not a problem, because the lock would be freed.

So this lead me to the decision that keeping old vector data fetching
API is not an option.

Martin