Is it possible to recreate cache tables from a more fixed source?

Brian Gradin

3/14/24, 6:20 PM

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:

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?

1 + 7

caching

Joseph

3/14/24, 6:36 PM

Probably a bigger question is why are you storing the database in version control?

Kevin

3/14/24, 6:40 PM

Yeah... don't do this. DB and uploaded files should not be part of a code repository.

Jaypan

3/14/24, 7:27 PM

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.

Brian Gradin

3/14/24, 8:23 PM

Basically I have three instances of the same site - two are used by developers, and one is a staging site. I want to sync all content, modules, themes, etc across all three environments.

Brian Gradin

3/14/24, 8:27 PM

The impulse to track things as code was because themes, modules, etc are already tracked in code, and the staging site is created using CI

Jaypan

3/14/24, 9:34 PM

Do you know about the Configuration API? https://www.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.

4uk4

3/15/24, 8:10 AM

@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.

Score:1

Drupal

4uk4

3/14/24, 8:30 PM

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

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Is it possible to recreate cache tables from a more fixed source?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.