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

Add db metadata to storage path #68

Open
joao-zanutto opened this issue Apr 14, 2024 · 3 comments
Open

Add db metadata to storage path #68

joao-zanutto opened this issue Apr 14, 2024 · 3 comments

Comments

@joao-zanutto
Copy link
Contributor

As discussed in #56, we'll be adding the Database name in the storage path to logically separate dumps without the need to change storage configuration when pointing Greenmask to different databases.

This will impact the commands below that will need to be adapted:

  • Dump
  • Restore
  • Validate
  • Show dump
  • List dump

Concerns:

  • What if the user have two different database hosts in the cloud with the same database name? (i.e. two RDS instances, one for dev and another one for production, but both have a greenmask database)
    • should the dbhost also be used in the path or will the user need to address that himself by adjusting a path/prefix value?
  • What if the config is defined like dbname: "host=localhost port=50022 user=foobar dbname=foobar" ?
    • should we disallow the dbname config to be declared like that or just parse the value?
@wwoytenko
Copy link
Contributor

  1. Well we could suggest in the documentation using the prefix parameter in the storage to isolate them. Or we could add one more level with the hostname provided --original-hostname. But I think it is redundant, a simple recommendation in the doc is enough. What if we are using localhost or UNIX socket in the connection string? I believe the simple doc recommendation is our choice.
  2. The simplest way to do so is to execute a query select current_database();, store the result, and apply it later

@joao-zanutto
Copy link
Contributor Author

  1. Gotcha, makes sense!
  2. How should I that be implemented so it can be used by the commands adapted to solve this issue? Should this query be added to internal/db/postgres/context or something like that?

@wwoytenko
Copy link
Contributor

@joao-zanutto

How should I that be implemented so it can be used by the commands adapted to solve this issue? Should this query be added to internal/db/postgres/context or something like that?

Right, all should be done in the RuntimeContext object. Create a new function let's say gatherCurrentDatabase and a new attribute DatabaseName. Assign the gathered database name to the RuntimeContext

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants