Since Drupal has a hook_flush_caches which allows modules to declare their own cache tables, I added a 'structure-tables-cache' option.
If added to sql-dump invocation, elevates bootstrap level to maximum possible and invokes all hook_flush_caches to build a list of cache tables and add them to the "only structure" table list.
It's working for me and IMO it is an easier (altough complimentary) way than fiddling with drushrc keyed lists.
Before carrying on with the todo I would like to have some feedback first.
Patch fixes minor whitespace, too.

TODO:
-Add 'skip-tables-cache' for autopopulate the skip-tables list
-Add [skip/structure]-tables-cache to sqlsync?
-Improve command options help text?

CommentFileSizeAuthor
drush--automatically-find-cache-tables-sql-dump.patch1.96 KBamontero

Comments

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Closed (won't fix)

Not so sure. That hook got renamed and clarified in D8 so that modules can do stuff there AND return bins that need to be cleared. I think that reflects what has always happenned in this hook so it would not be wise to flush stuff during a sql-dump. It would be nice if we had a hook where modules JUST returned bin names but no such hook exists in Drupal. You are probably better off retrieving all cache_* table names using a technique like #698264: Better handling of structure-tables and skip-tables options (including cache_* support!)

amontero’s picture

amontero
Location Barcelona
commented
Status: Closed (won't fix) » Active

Hi Moshe,

As far as I understand, hook_flush_caches returns an array with cache table names, but does not empties nor does anything with them:
http://api.drupal.org/api/drupal/modules!system!system.api.php/function/hook_flush_caches/7
I've not coded any module that does caching, so I only know what the docs tell. If there is some hidden quirk, it can be documented. If you can make some clarification worth ammending the docs, I will open an issue to ensure I'm the last one being tricked :)

So, I'm not sure about the possibility of some module doing nasty things in that hook, I don't know what you refer to with "has always happenned". Anyway, how unsafe would be possibly triggering some DB access before doing the dump to ensure we have a complete cache table list?

I understand that if it is a common practice to flush data or similar in that hook, that would be another different story. I'm not sure if there is some common/known "dirty trick" used here. In fact, I skipped the table 'cache_form' as Drupal core itself does when emptying caches to be safe. Maybe we should warn that this option can trigger DB access in the help screen and the docs if it's the case.

About the issue you mention, I already was aware of it, but thought that an added, non conflicting option that would not need any configuration in drushrc.php would be a nice addition. It's not quite exactly the same use IMO, although both issues partly overlap. For instance, this would avoid a (maybe edge, remote) case in which some contrib module does not name its cache bins starting with "cache_".

EDIT: Another possible advantage, it seems more easy when jumping to 8.x since we're using core hooks instead of manual lists. Do you need to have separate table keys listings for each Drupal major version in drushrc.php? I don't know how this it's currently addressed.

Thanks.

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Closed (won't fix)

Still Won't Fix. Since drushrc.php is a php file, you can do whatever processing you want to populate your structure-tables array.

amontero’s picture

amontero
Location Barcelona
commented

I set the issue to 'active' just to keep the thread open because I'm interested in learning the answers to my doubts above. Specially in case documentation can be improved. Is there some quirk with the flush_caches hook you know? (I'm still curious about "that reflects what has always happenned in this hook")

In case there is not any problem in invoking the hook, what is the point of not leveraging the "Drupal way"?

I didn't thought in doing the process in the drushrc.php, will try, thanks. Anyway, the whole point of the patch was to make it as easy as possible (=not tinkering with drushrc.php).

TIA.

moshe weitzman’s picture

moshe weitzman commented

Modules are clearing own caches during that hook. Whether they are supposed to do that or not is open for debate in D7 and below. I don't think any docs changes are needed. In D8+, that is OK according to the Doxygen.In D8 we hope to add a hook which is just for declaring cache bins. See #1167144: Make cache backends responsible for their own storage

amontero’s picture

amontero
Location Barcelona
commented

Thanks for the explanation, Moshe.
I've read the entire issue you mention and learnt lots of dirty secrets about the caching system :)
May I suggest postponing the feature request until the cache_bin_info hook it's implemented in 8.x?

moshe weitzman’s picture

moshe weitzman commented
Status: Closed (won't fix) » Postponed

Good idea.

greg.1.anderson’s picture

greg.1.anderson commented
Version: » 8.x-6.x-dev
Status: Postponed » Closed (won't fix)
Issue tags: +Needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.