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

Allow switching user databases #2006

Closed
3 tasks done
dmos62 opened this issue Dec 1, 2022 · 11 comments
Closed
3 tasks done

Allow switching user databases #2006

dmos62 opened this issue Dec 1, 2022 · 11 comments
Assignees
Labels
ready Ready for implementation type: meta List of related issues. Not meant to be worked on directly.
Milestone

Comments

@dmos62
Copy link
Contributor

dmos62 commented Dec 1, 2022

Tasks

  1. ready type: meta work: backend
    dmos62
  2. ready restricted: design team type: enhancement work: design
    ghislaineguerin
  3. needs: unblocking type: enhancement work: frontend
    pavish

Related:

@dmos62 dmos62 added type: enhancement New feature or request work: design work: backend Related to Python, Django, and simple SQL work: frontend Related to frontend code in the mathesar_ui directory labels Dec 1, 2022
@dmos62 dmos62 added this to the 01. First Release milestone Dec 1, 2022
@dmos62 dmos62 added the type: meta List of related issues. Not meant to be worked on directly. label Dec 1, 2022
@dmos62 dmos62 added the ready Ready for implementation label Dec 1, 2022
@dmos62
Copy link
Contributor Author

dmos62 commented Dec 6, 2022

This is not needed anymore for this cycle.

@kgodey kgodey modified the milestones: 2023 or later, Support for Existing Databases Dec 6, 2022
@kgodey kgodey modified the milestones: Support for Existing Databases, 2023 or later Jan 5, 2023
@pavish
Copy link
Member

pavish commented Mar 15, 2023

@dmos62

There are two existing issues (one for design, one for implementation) covering switching between databases:

This issue seems like a duplicate and I'd like to close it. Is there anything additional you'd like to handle in this issue that's not covered by the above?

@dmos62
Copy link
Contributor Author

dmos62 commented Mar 16, 2023

@pavish maybe let's keep this meta issue to track the whole of the feature? I replaced the design and frontend tasks with the issues you linked, and the backend issue is already linked.

@pavish pavish removed type: enhancement New feature or request work: design work: backend Related to Python, Django, and simple SQL work: frontend Related to frontend code in the mathesar_ui directory labels Mar 16, 2023
@pavish
Copy link
Member

pavish commented Mar 16, 2023

@dmos62 Sure, that works, thanks.

@kgodey
Copy link
Contributor

kgodey commented Mar 20, 2023

@pavish I think we should consider prioritizing this for 0.1.2 given #2716.

@pavish
Copy link
Member

pavish commented Mar 21, 2023

@kgodey I agree. It would also help with simplifying installation. I'll add it to 0.1.2 to prioritize it but I reckon it will take considerable time and testing. We can discuss this while discussing the plan for 0.1.2.

@pavish pavish modified the milestones: Icebox, v0.1.2 Mar 21, 2023
@dmos62
Copy link
Contributor Author

dmos62 commented Apr 7, 2023

@pavish maybe we should only have the owner of the feature assigned to this meta-ticket, and the people implementing the constinuent parts assigned to the respective sub-issues? At the moment all the people doing the sub-issues (except Mukesh) are assigned to this feature meta ticket.

@pavish
Copy link
Member

pavish commented Apr 7, 2023

@dmos62 We've so far been assigning everyone involved in a feature in the associated meta tickets, because sometimes we do not have sub-issues for all items in the meta ticket. I'm fine with it either way, if we only want to assign meta tickets to owners.

We don't have a well defined pattern for this yet. Perhaps you could discuss this with @rajatvijay.

@kgodey
Copy link
Contributor

kgodey commented Apr 7, 2023

I think it makes sense for the owner to be assigned, since they're responsible for the meta-ticket, driving the work and creating sub-tickets as needed.

@dmos62
Copy link
Contributor Author

dmos62 commented Apr 13, 2023

Made sure that backend supports multiple dbs in dev mode (completed #2007). Should be ready for frontend implementation (when designs are ready).

@pavish The steps for setting up another db locally in dev mode, by cloning the default db:

  1. Open a psql repl: sudo docker exec -it mathesar_db psql postgresql://mathesar:mathesar@mathesar_db:5432/mathesar -s
  2. In the psql repl, kill connections to the default db: SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'mathesar' AND pid <> pg_backend_pid();
  3. In the psql repl, clone the default db: CREATE DATABASE mathesar2 WITH TEMPLATE mathesar OWNER mathesar;
  4. Add the right entry into your .env's MATHESAR_DATABASES config entry by running this sed command: sed -i '/MATHESAR_DATABASES=(/ s/$/,(mathesar_tables2|postgresql:\/\/mathesar:mathesar@mathesar_db:5432\/mathesar2)/' .env
  5. Pick up the new configuration by restarting your docker compose setup: sudo docker compose --profile dev up

You should end up with a clone of your preexisting/default user database named mathesar2 in Postgres and mathesar_tables2 in Mathesar. Use GET http://localhost:8000/api/db/v0/databases/ to check.

@pavish
Copy link
Member

pavish commented May 18, 2023

Closing meta ticket since all items are handled.

@pavish pavish closed this as completed May 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready Ready for implementation type: meta List of related issues. Not meant to be worked on directly.
Projects
No open projects
Development

No branches or pull requests

5 participants