Editing configured database details

[Sean Colsen]

Team,

At some point we discussed the need to prevent users from editing details about database connections they’ve saved. We decided to prevent the user from changing the database name, server URL, and port. Does anyone recall when/why we decided this? I tried to find the meeting but couldn’t. What was the problem we were trying to avoid?

I don’t necessarily want to allow users to edit these details right now. But as part of database nicknames feature, I need to design and build a flow for users to edit the nickname. And I want to make it clear to users why they can’t edit the name, URL, and port as well.

I think we were trying to circumvent the complexity of keeping collaborators associated with a database and a role which are both associated with the same server. If the user changes the URL or port, then we would have some tricky questions to answer. Is that right?

What about the database name though? Lets say someone has renamed their database in PostgreSQL and they want to update the name in Mathesar so that they can connect to it again. If we let them do that, what problems would it cause?

I’m trying to get some clarity on this in order to appropriately design the flow for editing database nicknames.

​

[Ghislaine Guerin]

Hi Sean,

I've read through the Figma comments to find the origin for this restriction but didn't find anything particularly useful. It seems the idea was that users would have to disconnect and reconnect a database rather than modify its name, server URL, etc.

I'll see if I can find something else. 

Ghislaine

[Pavish Kumar Ramani Gopal]

> What about the database name though?

> If we let them do that, what problems would it cause

We wouldn't be able to know if it's the same database or a different one, with our current flow.

Allowing the user to modify the host, port, and db name would mean that we would have to either handle figuring out if it's the same database, or be okay with the fact that the user could modify an existing connection to a completely different database, or guide them thoroughly to ensure that they know what they're doing. We would also have to reduce user confusion that they are not changing the actual name of the underlying DB via the UI, but instead connecting to a different one.

These were some of the reasons we took into account while deciding not to let them edit the connection details.

All that said, it's safe to assume that changes to underlying database name, host, or port are extremely rare. We have to take into account if supporting that is worth our effort.

I would point out that DBAs connecting to external databases would be comfortable modifying the Mathesar internal Django database with the new connection details, if they want to preserve explorations. If they don't want to preserve anything, a new connection should suffice.