<div dir="ltr">I asked Jurgen to add the updateFeature a while ago in order to make the API feel a bit cleaner. My issue was that you could update the attribute values on the feature but you then still call changeFeatureAttribute for each attribute which seems really crap.  I really only want to update the feature and give it to the layer to handle calling the changeFeatureAttribute calls with the id, index, value stuff.  <div>

<br></div><div style>- Nathan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 16, 2013 at 8:13 AM, Martin Dobias <span dir="ltr"><<a href="mailto:wonder.sk@gmail.com" target="_blank">wonder.sk@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Going back to the older thread....<br>
<div class="im"><br>
On Sat, Mar 23, 2013 at 7:19 PM, Jürgen E. <<a href="mailto:jef@norbit.de">jef@norbit.de</a>> wrote:<br>
> On Sat, 23. Mar 2013 at 09:49:28 +1000, Nathan Woodrow wrote:<br>
>> Well the feature itself knows what values it started with. Every update in<br>
>> QgsFeature goes though the setAttribute, etc, call, you can just have an<br>
>> internal dictionary that logs when one of values is changed using those<br>
>> methods.<br>
><br>
> Sure, you could do that.  But what for?  Just for updateFeature?  That method<br>
> is not even used anywhere.<br>
><br>
> And one instance of QgsFeature is often used as buffer, so the tracking would<br>
> have to be reset at some point (setValid? setFeatureId?).<br>
><br>
> IMHO one needs to be aware that currently multiple iterators are not working<br>
> for now.  Maybe Martin can comment on this - I guess he has plans continue to<br>
> work on this and the current state is for the time being.<br>
<br>
</div>Maybe we should simply remove the updateFeature() function (or at<br>
least clearly document the side effect of issuing a request to the<br>
provider). Because of that request, even if the function worked in the<br>
nextFeature() loop, it would be highly inefficient to update features<br>
in such loop due to the many separate queries to the backend.<br>
<br>
Another reason for its removal would be that we do not use it anywhere<br>
in QGIS codebase and it's questionable to what extent it worked before<br>
the new vector API merge. For example, several providers used the same<br>
cursor for featureAtId() and nextFeature(), so the featureAtId() call<br>
during nextFeature() loop would re-create the cursor. Moreover,<br>
although OGR has a separate API calls for featureAtId(), OGR drivers<br>
that do not have efficient implementation of "get-feature-at-id" will<br>
simply fall back to internal "get-next-feature" loop, invalidating the<br>
reading state of nextFeature() loop.<br>
<br>
I have commented on multiple iterators in the other thread.<br>
<span class="HOEnZb"><font color="#888888"><br>
Martin<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div>