[Qgis-developer] problem with feature request and updateFeature

[Matthias Kuhn]

Hi,

On Sam 23 Mär 2013 19:19:59 CET, Jürgen E. Fischer wrote:
>
>> What do you think about introducing exceptions being thrown in such cases?
>
> No much.  We currently don't use exceptions at all (ok, at some internal
> places, but not in the API).   Qt doesn't use exceptions either.   I don't
> think it's worth to introduce exceptions just to workaround bugs.

We've got QgsException (although admittedly not used much) and anyone 
coding python plugins will be used to using exceptions. Is the usage of 
QgsException discouraged?

I agree, that it should not be used to work around bugs. Rather to 
discover them.

I'm not sure, if all dataProviders will be ready to support multiple 
connections for 2.0 and in case one needs to be closed before reaching 
the end, giving appropriate information to the developer would be nice 
(can also be a return value or whatsoever). It would be nice to hear 
Martin's ideas about this as well.

>
>> It would be easier to become aware and also to react to such problems.
>
>> There can also be conditions, when the underlying data is edited while
>> being iterated. I remember Java had something called fail-safe and
>> fail-fast iterators, which might be worth revising for this case.
>
> Can that work without revisiting the feature in the database?

I think so. For e.g. Postgres we probably don't need to care. Iterators 
coming from the database should be fail-safe anyway.
For other data sources, which do not provide safe iterators, handling 
changes that come from within QGIS are traceable, while for changes 
from outside appropriate signaling from the dataProvider would need to 
be guaranteed (if not yet implemented). But I may have missed something 
here and I think you know the dataProvider internals better than I do 
to estimate the current state of change-tracking possibilities, so 
please take this with a pinch of salt.

Matthias