Comment 2 for bug 1751040

Hi

The proposal is twofold:
1) At the moment, unless I am missing some configuration, CLI client does not specify which 'fields' it wants to see. So they are not filtered out by the db_utils.resource_fields(res, fields). I do agree that when the 'fields' argument is passed in API that also the fields of the extensions are filtered out. However they are still calculated, that is point 2.

2) I would only do the second part that you propose, "Then extensions could also do additional filtering by themselves in case when they serve multiple fields.", which would leave it in the hands of each extension if they need to act or not. If you deem it necessary I could also look at "we would need to know which fields are generated by each registered extension," but I believe that would require more extensive changes.

The architecture that I had in mind was to change the signature of extended functions:
resolved_func(response, db_object, fields) instead of resolved_func(response, db_object). This would mean either wrapping around legacy functions based on inspection (this would be on registration) or try-catch on execution. A new registration api is also a possibility, I do not know what the ideal situation here would be.
To be effective it would also mean changes in ML2 extension drivers, but I believe that requires fewer changes as it uses inheritance instead of registration.