Is your feature request related to a problem? Please describe.
I choose to deploy the password secret via the full DSN when deploying clickhouse secrets to my analytics environment because deploying 1 secret makes administration easier. My password contains special characters. I think generally these should percent-encoded and it doesnt look like clickhouse-driver supports that like sqlalchemy does. I have worked around this for now by just mounting a clickhouse password as the podman secret, but I would prefer if I could just deploy the full DSN as a secret.
Describe the solution you'd like
clickhouse_connect.driver.create_client(dsn="https://username:pass%20word@host:port/database") should use the password "pass word" (not my real password :))
Describe alternatives you've considered
I can parse the DSN on the client side and instantiate the client with expanded kwargs, but it seems like DSN should work and allow percent-encoded password (and probably username+database, but those are more likely to have 'simple' names whereas password probably should have special characters.
Additional context
Sqlalchemy treats username+password+database as percent-encoded and decodes them
If we agree with this change, I can bang this out quickly.
Is your feature request related to a problem? Please describe.
I choose to deploy the password secret via the full DSN when deploying clickhouse secrets to my analytics environment because deploying 1 secret makes administration easier. My password contains special characters. I think generally these should percent-encoded and it doesnt look like clickhouse-driver supports that like sqlalchemy does. I have worked around this for now by just mounting a clickhouse password as the podman secret, but I would prefer if I could just deploy the full DSN as a secret.
Describe the solution you'd like
clickhouse_connect.driver.create_client(dsn="https://username:pass%20word@host:port/database")should use the password "pass word" (not my real password :))Describe alternatives you've considered
I can parse the DSN on the client side and instantiate the client with expanded kwargs, but it seems like DSN should work and allow percent-encoded password (and probably username+database, but those are more likely to have 'simple' names whereas password probably should have special characters.
Additional context
Sqlalchemy treats username+password+database as percent-encoded and decodes them
If we agree with this change, I can bang this out quickly.