-
Notifications
You must be signed in to change notification settings - Fork 277
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
Support all DSN variants for clickhouse DATABASE_URL #489
Comments
I would be in favor of supporting this "experimental" HTTP transport, based on the ClickHouse README change on Jul 8, 2022 and still marked experimental today, as long as the database URL driver is prefixed, for example, |
Related discussion: #474. |
Well, even if we do add the support for http client for clickhouse, this won't change the fact you will need to use a different DATABASE_URL for dbmate, as we still need a db-specific prefix to map to the correct driver. @dossy In my opinion, we can just the update the scheme to be "http" instead of "clickhouse" in case the user provided a port of "8123" (http) or 8443 (https). What do you think? |
I'm not a fan of the idea of using the port number to infer the transport layer: it could lead to unintended surprises when a user, not aware of this "magical" association, uses a port that suddenly changes the transport layer. We often use the same port numbers for particular services out of tradition, because most services are not officially registered with IANA. But, ultimately, port numbers are arbitrary: there is nothing technically stopping you from running your database bound to port 1/tcp, aside from some antiquated "binding to privileged ports" restriction which is simply a matter of configuration, or using a port redirection like NAT. Requiring a user to specify the transport in the URL, e.g., Now, I think the idea of defaulting the port, if not specified in the URL, depending on the URL scheme, may make sense if there is an expectation that a particular port will be used by default. In other words, specifying |
Thanks for the elaborated response, I agree with the reasonings + I think that supplying the default based on scheme is a great idea. I think I will try to tackle this one |
Agree with @dossy, we cannot register something generic like If we want to support interop with existing clickhouse connection strings, then we could potentially offer a new optional CLI flag to override the driver. For example something like: dbmate --url "http://default:changeme@localhost:8123/default" --driver clickhouse up Thus the clickhouse driver could support both |
I'm in favor of this approach, because ClickHouse users can use the same |
Yeah |
Description
Hello, the clickhouse driver should support all DSN variants. Currently, I need to pass two connection strings to use dbmate with an application that uses clickhouse HTTP protocol.
Steps To Reproduce
Expected Behavior
HTTP should just work. The clickhouse driver has a
clickhouse.ParseDSN
function that does the job for all variants. I can provide a PR.The text was updated successfully, but these errors were encountered: