Skip to content
This repository has been archived by the owner on Dec 1, 2018. It is now read-only.

How to properly persist database changes? #171

Open
rootical opened this issue Sep 26, 2016 · 4 comments
Open

How to properly persist database changes? #171

rootical opened this issue Sep 26, 2016 · 4 comments

Comments

@rootical
Copy link

rootical commented Sep 26, 2016

Hello guys, thanks again for your hard and nice work.

I have a question which is really basic and obvious and not really an issue, but I would like to hear your thoughts on that.

What is a database persistency workflow? While developing using drude, how do you do that?

How to make sure database changes wouldn't be erased when calling a dsh init, for instance?
Shall I commit db changes to mysql container, shall I add a volume for it? And then just replace site installation in init script to actual import of a dumb? Or, again, a volume would be better here? What about multiple people working in parallel on something, how would merge database changes then?

A one-two sentence in drude readme could help a lot with this.
Thanks in advance.

@achekulaev
Copy link
Contributor

achekulaev commented Sep 26, 2016

Hi @rootical

Thanks for bringing this up. Due to the use of volumes it is really a non-trivial operation to create truly persistent database.
If your database is not too big the easiest way is to dsh sqli your_dump.sql whenever you need. You could modify init script to do that if you need.

If re-importing is not an option then it gets trickier. In two sentences you'd need to modify docker-compose.yml so that db didn't use volume (then you'd need to re-create container with dsh reset db), then import database, then commit a container creating a new docker image and then change docker-compose.yml to use you newly created image for your db container instead of the default one it uses.

We will be creating more detailed instruction in the future as I believe it is a feature many would want to know how to use.

@lmakarov
Copy link
Owner

@rootical this really depends on what you are trying to achieve. You mentioned too many things and it's not clear what it is that you are trying to achieve.

The database is generally persistent so long as you do not destroy it along with other containers with dsh init or dsh reset. You will also lose everything if you drop Drude's boot2docker VM.
Restarting the VM or containers will not reset the DB for a project.

Everything else is up to you. Make dumps, store them somewhere, update the init script to import DB from a dump instead of installing a site from scratch.

In our development workflow we would import a DB from a remote server (via drush) or from a local file (stored in Git LFS or downloaded via other channels).

@rootical
Copy link
Author

Thanks for your answers, folks! Appreciate it. My bad, too many questions raised. But this is something very important and I guess prevents a number of people from using drude based setup.

So far I can see the easiest way is to just work with dumps. But I would really appreciate just a step-to-step guide on how to do what @achekulaev suggests not to not run into many issues.
One thing not really clear is that @achekulaev suggested to modify docker-compose and remove volume out there (but it doesn't have it by default). Anyways, if you could provide some guide everybody will benefit from it.

Another thing to recap which is not really clear - is how could different people work on the same database source. Probably there should be an option with remote connection to a daemon or similar, have you already considered something like this?

@lmakarov
Copy link
Owner

I would really appreciate just a step-to-step guide on how to do what @achekulaev suggests not to not run into many issues.

I believe what @achekulaev was referring is the DB sandbox mode. This is a pretty advanced use case and is documented here:
https://github.com/blinkreaction/drude/blob/develop/docs/db-sandbox.md
These docs are most likely outdates at this point. Take a look and if that's what you are really looking for, we can revise them.

how could different people work on the same database source

Again, please be more specific:

  • Do you want to have a container with a pre-loaded DB snapshot (DB sandboxing)?
  • Are you trying to share DB snapshots with others on the team?
  • Are you trying to use the same DB container with multiple clients/hosts/users in a local network?
  • Do you want the DB to persist even if the DB container or entire VM is reset?
  • < Your use case here >

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

No branches or pull requests

3 participants