<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>