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.
- Nathan On Tue, Apr 16, 2013 at 8:13 AM, Martin Dobias <[email protected]> wrote: > Going back to the older thread.... > > On Sat, Mar 23, 2013 at 7:19 PM, Jürgen E. <[email protected]> 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 > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
