[Qgis-developer] problem with feature request and updateFeature

[Martin Dobias]

Going back to the older thread....

On Sat, Mar 23, 2013 at 7:19 PM, Jürgen E. <jef at norbit.de> wrote:
> On Sat, 23. Mar 2013 at 09:49:28 +1000, Nathan Woodrow wrote:
>> Well the feature itself knows what values it started with. Every update in
>> QgsFeature goes though the setAttribute, etc, call, you can just have an
>> internal dictionary that logs when one of values is changed using those
>> methods.
>
> Sure, you could do that.  But what for?  Just for updateFeature?  That method
> is not even used anywhere.
>
> And one instance of QgsFeature is often used as buffer, so the tracking would
> have to be reset at some point (setValid? setFeatureId?).
>
> IMHO one needs to be aware that currently multiple iterators are not working
> for now.  Maybe Martin can comment on this - I guess he has plans continue to
> work on this and the current state is for the time being.

Maybe we should simply remove the updateFeature() function (or at
least clearly document the side effect of issuing a request to the
provider). Because of that request, even if the function worked in the
nextFeature() loop, it would be highly inefficient to update features
in such loop due to the many separate queries to the backend.

Another reason for its removal would be that we do not use it anywhere
in QGIS codebase and it's questionable to what extent it worked before
the new vector API merge. For example, several providers used the same
cursor for featureAtId() and nextFeature(), so the featureAtId() call
during nextFeature() loop would re-create the cursor. Moreover,
although OGR has a separate API calls for featureAtId(), OGR drivers
that do not have efficient implementation of "get-feature-at-id" will
simply fall back to internal "get-next-feature" loop, invalidating the
reading state of nextFeature() loop.

I have commented on multiple iterators in the other thread.

Martin