0

I am working with a dockerized Drupal environment in which we want to track content alongside our theme, modules, etc in source control. We achieve content tracking by using mysqldump to dump the database to disk, with one table per file. Then when the environment is created using Docker Compose, the SQL files on disk recreate the database state. We also track certain files from sites/default/files like uploaded images and copy those to the Drupal container on environment start.

Whenever we make a change in our environment, we want to persist the change in our source control by overwriting the SQL files on disk, but even for innocuous changes like logging in a user and logging them back out (theoretically ending up where you began), there are a lot of modified tables:

modified tables

Several of these are related to user data, but they are mostly caching-related, and the same tables change for other innocuous changes.

Ideally I'd like to prevent "noise" in our commits by minimizing the number of modified files whenever we make a content change. For these cache tables, is it possible to only track their table CREATE statement and not the content of the cache, and just recreate the cache content somehow when we spin up a new instance of the Docker environment?

Improve this question
7
  • 2
    Probably a bigger question is why are you storing the database in version control?
    – Joseph
    Commented Mar 14, 2023 at 18:36
  • Yeah... don't do this. DB and uploaded files should not be part of a code repository.
    – Kevin
    Commented Mar 14, 2023 at 18:40
  • 2
    As others have said, storing DB dumps in a repo does not really make sense. There are likely better ways to track whatever it is you want to track. If you include your use case, for example how a client who is not technical would explain it, we could probably provide solutions that work well with Drupal.
    – Jaypan
    Commented Mar 14, 2023 at 19:27
  • 1
    Do you know about the Configuration API? morpht.com/blog/drupal-8-configuration-part-1-configuration-api. This combined with the Migrate API is the complete solution to sharing configuration and content between environments.
    – Jaypan
    Commented Mar 14, 2023 at 21:34
  • 1
    @Jaypan, the tutorial is great, for the standard use case. The OP has a different use case which is not that uncommon by the way. I also found myself in that position and docker/kubernetes is an efficient way to deploy such sites. It all depends on what you need to persist and what you can discard when spinning up a new pod.
    – 4uk4
    Commented Mar 15, 2023 at 8:10

1 Answer 1

Reset to default
1

To spin up the Drupal container you don't need the content of cache_* and watchdog tables. You could use Drush with the option --structure-tables-list, but it should be no problem to replicate this in custom code:

drush sql-dump --structure-tables-list=\
cache_bootstrap,cache_config,cache_container,\
cache_default,cache_discovery,cache_entity,\
cache_menu,cache_toolbar,cache_data,\
cache_dynamic_page_cache,cache_page,\
cache_render,watchdog \
> mysite.sql
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.