-
Notifications
You must be signed in to change notification settings - Fork 14.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OdbcHook string values in connect_kwargs dict converts to None #15016
Comments
Thanks for opening your first issue here! Be sure to follow the issue template! |
I can take it, if you don't mind |
@krnhotwings this function is useful because the The |
@marcosmarxm Sorry, but I'm still not entirely sure why It looks like airflow/airflow/models/connection.py Line 335 in db9febd
Looking at the documentation you linked, I noticed the quoted JSON boolean values in the very last example code block, but I would think that it should all work correctly with unquoted raw JSON booleans, which should make For example, if you created a connection {
"connect_kwargs": {
"DummySetting": true
}
} it should yield: >>> airflow.providers.odbc.hooks.odbc.OdbcHook('myconn').connect_kwargs
{'DummySetting': True} Am I missing something else? (Again, pardon any ignorance on my part.) |
@krnhotwings you are correct and nice work diving into this. Maybe this is just legacy structure that keep until nowadays. |
@marcosmarxm Yes, I have tested in 2.0.2 and have my extras as follows: {
"connect_kwargs": {
"CurrentSchema": "TEST",
"Blah": true,
"Blah2": false
}
} >>> from airflow.providers.odbc.hooks.odbc import OdbcHook
>>> OdbcHook('myconn').connect_kwargs
{'CurrentSchema': None, 'Blah': True, 'Blah2': False} (Had to double-check today. It was getting late last night.) |
@marcosmarxm I have removed {
"connect_kwargs": {
"CurrentSchema": "SCHEMA",
"Blah": true,
"Blah2": false
}
} >>> from airflow.providers.odbc.hooks.odbc import OdbcHook
>>> OdbcHook('myconn').connect_kwargs
{'CurrentSchema': 'SCHEMA', 'Blah': True, 'Blah2': False} As the next step, I will make and commit the changes within the PR #15510 |
TLDR I agree we should remove As to why it was put in, in the first place, here's what I think happened. Observe what happens with airflow's connection URI format when we try to pass a boolean value: >>> c = Connection(conn_id='hello', uri='hello://?my_val=True')
>>> c.extra_dejson
{'my_val': 'True'} It's impossible to produce a json object with boolean values. So when you are using top level key-value pairs in conn I suspect maybe initially in the development of this hook the connect kwargs were top level within But when dealing with nested json, the boolean vs. string issue becomes irrelevant and you have new problems to solve. Namely, at the time this hook was merged, airflow's conn URI did not support nested json. So this hook did not actually allow for storage of So since |
* OdbcHook returns None. Related to #15016 issue. This PR is related to #15016 issue. OdbcHook returns None for non-boolean-like string values in connect_kwargs dict arg, however connect_kwarg values should remain as is in this case. According to the discussion on #15016, we agreed to remove the clean_bool function, as it is not needed actually for processing boolean values in JSON .
Apache Airflow version: 2.0.1
What happened:
OdbcHook
returnsNone
for non-boolean-like string values inconnect_kwargs
dict argWhat you expected to happen:
connect_kwarg
values should remain as is.How to reproduce it:
Anything else we need to know:
The issue lies in:
airflow/airflow/providers/odbc/hooks/odbc.py
Lines 170 to 173 in db9febd
There's no
else
block that returnsval
. As it is, any string value will instead returnNone
.Pardon my ignorance on the subject, but this raises a question: Why is
clean_bool
being called in the first place for a user-provided dictionary? I'm not sure how this is necessary because the user can provide a literal boolean value in the dictionary if needed, no? If in the event that a driver needs to take a case-sensitive boolean string for some parameter, thenclean_bool
would make it impossible to provide such a value.The text was updated successfully, but these errors were encountered: