[Qgis-developer] [Python] QgsFeatureIterator for geometryless PostgreSQL-Layer

[Martin Dobias]

On Tue, Apr 16, 2013 at 8:27 AM, Jürgen E. <jef at norbit.de> wrote:
> Hi Martin,
>
> On Mon, 15. Apr 2013 at 23:45:20 +0200, Martin Dobias wrote:
>> > BTW what about parallel iterators?  I suppose there were problems and thats
>> > why you added the "active iterators" - do you recall which providers were
>> > affected and how?
>
>> I have modified providers to have pointers to active iterators because of two
>> reasons: 1. if the user asks for a second iterator and the provider does not
>> support multiple iterators, the first one has to be closed - they would not
>> behave correctly if used together
>
> IMHO that's not ok.  If the provider doesn't support multiple iterators, the
> second on should be rejected - forcing the caller to close the other one first.

You're right - when thinking about it again, it makes more sense to
reject new iterator rather than close the previous one with force. It
should be relatively simple to swap the behavior.


> As we lost the ability to do featureAtId while iterating a layer, we now have a
> couple of places, where stuff behaves strange and it's not really obvious that
> it's causes by a setFilterFid request killing a surrounding iteration.

In the other thread (about updateFeature()) I have noted that we
actually never really supported featureAtId while iterating a layer -
at least not in all providers... AFAIK postgis always used only one
cursor. With OGR provider that could work - but maybe just for some
drivers (e.g. shapefile). If I have time I will try to do few tests
how qgis 1.8 behaved.


> Rejecting it wouldn't cure that, but at least make is show (ok, that's what the
> error message does also do that now).  And unless we get the parallel
> setFilterFid request back, we'll need to identify and rewrite the looping code.

When porting the code to new API, were there really loops that
combined nextFeature() with featureAtId() ?

Martin