AIP-84 Migrate patch a connection to FastAPI API

[bugraoz93]

closes: #42592.
Include, making fields nullable for patch endpoints for backward compatibility.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[pierrejeambrun]

I think we should also make consistant the behavior for PATCH regarding None value.

Here when there is a mask you take them. And when there is no mask, you filter them out.

I did something different for Pool which I think can be extented. When there is a mask, same thing, we use values. When there is no mask, we validate that the payload is valide by it's own, i.e it's a valid db entity by its own, and we use everything. (none or not).

The idea is to allow someone to not specify mask and reset some fields to None if needed.

[pierrejeambrun]

I just pushed one commit to remove a remnent of old code _parse_comma_separated_query_params. PR rebased. Should be good to merge.

[pierrejeambrun]

I think we have the same issue here, we cannot update the password field. This should be possible, and the returned password should be redacted I believe. Otherwise we have no way for a user to update the password of a connection, or set it (event the POST create connection does not allow it in its current state.)

[bugraoz93]

I just pushed one commit to remove a remnent of old code _parse_comma_separated_query_params. PR rebased. Should be good to merge.

I totally missed this one, thanks for the changes! :)

[bugraoz93]

I think we should also make consistant the behavior for PATCH regarding None value.

Here when there is a mask you take them. And when there is no mask, you filter them out.

I did something different for Pool which I think can be extented. When there is a mask, same thing, we use values. When there is no mask, we validate that the payload is valide by it's own, i.e it's a valid db entity by its own, and we use everything. (none or not).

The idea is to allow someone to not specify mask and reset some fields to None if needed.

I think I looked from the lazy path when no parameter, no value to you :) Saw your changes. Looks good and makes sense! I agree, we should have a common approach for common methods because what we are doing at the end is pretty similar.

[pierrejeambrun]

For 'common' behavior of null values we can do that in another PR. That is not really specific to this one. I think we can just handle the 'password', then merge it, maybe you can take care of making all PATCH consistent regarding none values in a follow up, if that sounds good ?

[bugraoz93]

For 'common' behavior of null values we can do that in another PR. That is not really specific to this one. I think we can just handle the 'password', then merge it, maybe you can take care of making all PATCH consistent regarding none values in a follow up, if that sounds good ?

Yeap, it sounds perfect! I am going to take care of that after finishing the password part. There is a small work left for password. I couldn't make redact work in the tests, which I will check it out today and push it to both PRs related to this

[pierrejeambrun]

We need to handle the password

[bugraoz93]

Tests should be fixed in #43654.

[pierrejeambrun]

Looking good.

Need rebasing to fix conflicts, we can merge after.

[bugraoz93]

Looking good.

Need rebasing to fix conflicts, we can merge after.

Many thanks for rebasing and merging the other PR! You saved me from facing the conflict twice 🙏 Rebased.