-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
CLI quickstart: Drop asking for database connection parameters in favor of connection string #16093
Conversation
mysql: [connection_string], | ||
pg: [connection_string], | ||
cockroachdb: [connection_string], | ||
oracledb: [connection_string], | ||
mssql: [connection_string], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it common for all these databases to rely on a connection string? From what I understand, Oracle relies on a "connect string" (instead of "connection string"), and for mysql/mssql is still more common to use parameters right? 🤔
(Also lets use camelCase
for variable names in the codebase 👍🏻 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say using separate parameters is still very common among webdevelopers. Some accompanying docs would be needed to instruct users how to build such a connection string for engines that don't provide it on startup like MySQL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rijkvanzanten Another thought, what if we kept the separate parameters...but the first parameter is Host or Connection URL and then we detect if it is a connection string skip the rest of the parameters? Allows people to use both ways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rijkvanzanten Another thought, what if we kept the separate parameters...but the first parameter is Host or Connection URL and then we detect if it is a connection string skip the rest of the parameters? Allows people to use both ways.
In that case, I'd rather start with a question:
Use:
(•) Connection string
( ) Individual Parameters
But tbh, it feels like we can have smart enough defaults by using connection string for postgres/cockroach/oracle, and parameters for everything else
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes more sense, however, I wonder how this will affect people used to the default values? With this change won't they have to make their own connection string and there will be no defaults?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it common for all these databases to rely on a connection string? From what I understand, Oracle relies on a "connect string" (instead of "connection string"), and for mysql/mssql is still more common to use parameters right? thinking
(Also lets use
camelCase
for variable names in the codebase 👍🏻 )
Yes you're right. I'll make those updates today :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rijkvanzanten Another thought, what if we kept the separate parameters...but the first parameter is Host or Connection URL and then we detect if it is a connection string skip the rest of the parameters? Allows people to use both ways.
In that case, I'd rather start with a question:
Use: (•) Connection string ( ) Individual Parameters
But tbh, it feels like we can have smart enough defaults by using connection string for postgres/cockroach/oracle, and parameters for everything else
I'm for this. Supporting both connection params and individual params, by asking the question after the user select their DB client.
Closing this for now as the suggested solution doesn't cover all use cases. See the thread here! 🙂 #16093 (review) |
Description
Fixes #16066
Type of Change
Requirements Checklist
If adding a new feature: