Don't loop through all selected features multiple times (once per field) when the attribute form is opened

[nyalldawson]

This is incredibly expensive, yet only required in a very very small
corner case (field is from a joined layer without the upsert on edit
capabilities).

Refine logic to avoid the scan wherever we can.

Fixes #41366

[nyalldawson]

@rduivenvoorde can you test please?

[rduivenvoorde]

compiling....

[rduivenvoorde]

Thanks Nyall!

If I test the steps from the issue with that downloadable osm dataset, it works! No more freezing/blowing fans...

I also tried if the 'multi edit' was working, and that seems to work OK.

Did this come from #31234 ? I do see multi edit buttons, but I'm not sure how to test the auxiliary storage attribute buttons...

Ok, I tried using https://oslandia.com/en/2017/10/17/auxiliary-storage-support-in-qgis-3/

So I moved some labels using fid as primary key, and then in the form the multi edit looks like this (aka I see a button there...):

@troopa81 can you maybe test this better?

[uclaros]

@nyalldawson Wouldn't it make sense to have all code in void QgsAttributeFormEditorWidget::updateWidgets() handled inside the switch( mode() ) conditional? Why bother at all with edit form widgets when we only use the search form?

[nyalldawson]

@uclaros

I agree - but I was trying to fix the deeper cause of the slowness here, since it would also affect use of the form in multi edit mode.

[gioman]

I also tried if the 'multi edit' was working, and that seems to work OK.

@rduivenvoorde @nyalldawson does this patch helps with #36863 ?

[uclaros]

I agree - but I was trying to fix the deeper cause of the slowness here, since it would also affect use of the form in multi edit mode.

Yes, that I saw, and totally agree with the treat the cause, not the symptom idea. But while there, it might be a good idea to separate the logic of the search and edit form, those are needlessly mixed and might cause trouble in the future.

[nyalldawson]

@gioman

does this patch helps with #36863 ?

Should do, yes

[nyalldawson]

@uclaros does 724e1ba look right to you?

[uclaros]

@uclaros does 724e1ba look right to you?

Can't the logic be handled in a single switch( mode() ) ? Two consecutive same switch statements look weird.

[nyalldawson]

Can't the logic be handled in a single switch( mode() ) ? Two consecutive same switch statements look weird.

I agree it looks odd, but they are handling completely different logic. I can't see any clean way to avoid this without unnecessary code duplication.