Field calculator: provide a list of default field types

[elpaso]

in case the provider does not (WFS is one of them).

Rationale: consider that there is not such
a thing like a list of supported types for WFS
and parsing the particular describeFeatureType
for the layer would restrict the types to only
those actually existing in the layer, but
we are dealing with virtual fields here (because
WFS has no column add capabilities) so
let's give the users a minimal set of useful
types to play with.

Fixes #21086

[nyalldawson]

Could an alternative solution be to move this default list to wfs provider as its (estimated) native types? It would also fix the issue for the add column actions at the same time then.

[elpaso]

Could an alternative solution be to move this default list to wfs provider as its (estimated) native types?

Yes, it's the alternative solution, just move this piece of code into WFS provider.
I thought about it and I felt that it was advantageous to put the default in the field calc, because it would have covered the case of other (future) providers that do not have a list of types (maybe because like WFS there is no list of standard types).

But I'm totally fine with moving the code in the provider.

It would also fix the issue for the add column actions at the same time then.

What issue? (WFS does not allow to "alter table")

[nyalldawson]

Ah ok, I didn't realise you couldn't add fields here. (But wouldn't that also affect field calculator?)

In any case, I think this those belong in the wfs provider, with other affected providers also setting their own list of reasonable fallback defaults.

[elpaso]

Ah ok, I didn't realise you couldn't add fields here. (But wouldn't that also affect field calculator?)

We are talking about virtual fields here, it's a legitimate use case even if the data source has no addColumn capabilities.

In any case, I think this those belong in the wfs provider, with other affected providers also setting their own list of reasonable fallback defaults.

AFAIK the WFS is the only one which does not override the default implementation (which is an empty list of field types) , but there is also a possibility to add this default list to the base class: it's a sensible minimal subset.

[elpaso]

@nyalldawson forgot to mention that a reason for NOT adding the defaults to the provider is side effects where the list of fields is used outside of the field calculator (I did not check), by adding the default inside the field calculator class we can be absolutely sure that there are/will-be no other parts of the code affected by seeing a list of field types coming from a data source without addColumn capabilities.

[nyalldawson]

Hmm, ok. Sorry I missed the original issue here. But then - shouldn't we ALWAYS allow ALL field types for virtual fields?

[elpaso]

Maybe, even if I don't really find a good reason to add all variants of numeric integers and floating point types: there is no storage involved here. This is why I chose the minimalist approach.

[elpaso]

Oh, sorry I missed the "always" part. Yes, I agree that virtual fields should "always" share the same field type set.

[elpaso]

@nyalldawson see my last commit