greenmask icon indicating copy to clipboard operation
greenmask copied to clipboard

Add db metadata to storage path

Open joao-zanutto opened this issue 1 year ago • 3 comments

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?

joao-zanutto avatar Apr 14 '24 22:04 joao-zanutto

  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

wwoytenko avatar Apr 16 '24 08:04 wwoytenko

  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?

joao-zanutto avatar Apr 16 '24 19:04 joao-zanutto

@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

wwoytenko avatar Apr 16 '24 19:04 wwoytenko