Should the CLI allow persisting a default port and duration per connection?

[mmacvicar]

I really feel the need of this for usage together with other tools without needing to specify ports all of the time. For example, people using a database GUI with multiple connections, local development environemnts that need some remote resources.

[sandromello]

Hey @mmacvicar ,
I understand that these GUI tools requires a hostname and port. Do you think having static hostnames or having a command to connect in multiple resources could enhance this experience? Could you elaborate more on that please?

[mmacvicar]

I have 2 use cases and a risk that appear in my day to day:

• Analysts some times request access to one of multiple production databases. They keep them configured in DBeaver. If the local por does not remain the same, they need to update the connection in dbeaver whenever it changes.
• Our developers open multiple connections to staging environments (postgres and TCP to redis and rabbitmq). They do this to run local code against those environments. Starting multiple connections with hoop is not much a problem, particularly if this stop is part of a setup they run once. However, when they do start a connection manually, they need to remind which port was used for that connection to avoid changing ports across local configuration.

Then the risk, with a story. Once at a quite big public company we had a major outage due to random flushes sent to a redis cluster in production. Of course it was due to a mistake, a developer had requested production access for valid reasons, created an ssh tunnel, used it and went on with his routine. However, he did not realized the tunnel stayed alive, thanks to authossh, at the same default por thtan the testing environment, fluhsing it with every local test run. I see a similar risk if a database is accessed by default in port 40000 with the same user and password noop (which I believe is ignored anyways). People might potentially use a database thinking it was a different one (assuming at least the db name is the same, which is not that rare).

The way I would solve this is by being able to configure a default port, so each connection could default to different ports, allowing for better standarization and reducing that risk I mentioned. This port could just live as defaults values for connections for the CLI and the desktop client.

Does it make sense?

[sandromello]

Hey @mmacvicar ,

Thank you for providing such detailed feedback on this use case. Your insights are valuable and your points are well-taken. We'll be discussing this internally to identify specific improvements to enhance the user experience.

I'll keep you updated on our progress. If you have any additional thoughts or suggestions in the meantime, please don't hesitate to share them.