Skip to content
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

Implement new "connections" model and API #3291

Closed
Tracked by #3294
seancolsen opened this issue Nov 3, 2023 · 2 comments · Fixed by #3309
Closed
Tracked by #3294

Implement new "connections" model and API #3291

seancolsen opened this issue Nov 3, 2023 · 2 comments · Fixed by #3309
Assignees
Labels
ready Ready for implementation restricted: maintainers Only maintainers can resolve this issue type: enhancement New feature or request work: backend Related to Python, Django, and simple SQL
Milestone

Comments

@seancolsen
Copy link
Contributor

Current behavior

We have a "databases" API which has developed some cruft and does not suit our changes in direction for v0.1.4.

Desired behavior

We should have a new "connections" API which behaves as follows

  • Use the endpoint /api/db/v0/connections/
  • Have a "nickname" field that can be changed. Nicknames must be unique across all connections within one Mathesar installation.
  • Not have deleted or editable fields, as in the current "databases" API.
  • Write and read connections only to and from the internal (Django) database. (This is in contrast to the old databases API which considered the environment variables to be a second source of truth for user database connections.)
@seancolsen seancolsen added restricted: maintainers Only maintainers can resolve this issue status: draft type: enhancement New feature or request work: backend Related to Python, Django, and simple SQL labels Nov 3, 2023
@seancolsen seancolsen added this to the v0.1.4 milestone Nov 3, 2023
@mathemancer mathemancer self-assigned this Nov 8, 2023
@seancolsen seancolsen added ready Ready for implementation and removed status: draft labels Nov 9, 2023
@mathemancer
Copy link
Contributor

mathemancer commented Nov 10, 2023

Getting into implementing this.

@seancolsen I suggest making the following change as well: Changing the field db_name to simply database .

  • db_name is the cause of a bunch of confusion in the back end.
  • database is how the property of a connection is referred to in postgres (and other documentation).
  • I'd want to go this direction anyway in the long run, may as well do it now if it's not a huge problem.

Normally, I'd just go for it, but I think this implies some front end work, and I know we're trying to get this done quickly. What do you think? Is it a huge hassle to change on the front end?

@seancolsen
Copy link
Contributor Author

@mathemancer database sounds fine to me. Go for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready Ready for implementation restricted: maintainers Only maintainers can resolve this issue type: enhancement New feature or request work: backend Related to Python, Django, and simple SQL
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

2 participants