Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Drush rr completes by clearing the Drupal caches. This should not occur, IMO. During deployment you may need to customize the order in which certain tasks occur. Registry rebuild is typically the first task to run, but there are often times that you need drush updb to run prior to any caches being cleared, for instance if schema changes have occurred that would cause the cache clearing to fail with an Exception.
Comment | File | Size | Author |
---|---|---|---|
#8 | registry_rebuild-1298422-no-cache-clear-8.patch | 1.07 KB | q0rban |
#2 | no_cc_all-1298422-1.patch | 734 bytes | apotek |
Comments
Comment #1
apotek CreditAttribution: apotek commentedThis is INSANE! I was just thinking about this, and someone posted this analysis seconds before I was about to.
Thanks q0rban. A valid point. Functions should generally do one atomic thing--especially when there already are functions available to do the other parts.
ie, its better to write registry rebuild so it can be invoked
drush rr
with an *optional*
drush cc all
if the end-user wants it.
Man oh man.
Comment #2
apotek CreditAttribution: apotek commentedHere's a patch.
Comment #3
rfaydrush rr is now a part of a deployment process? I thought it was just a rescue thing.
I'm OK with just telling them they ought to clear the cache instead of doing it for them.
Comment #4
q0rban CreditAttribution: q0rban commentedIt's becoming a part of our deployment process, because if any classes get removed or deleted, you can't run drush updb or drush cc all or drush fra. So immediately after a git pull, we run drush rr.
The other things we could do is make it an option on the drush command, or wrap the cache clear in a try/catch, or invoke the cache clear using drush_invoke. Not sure the latter two would work, but the first would be simple enough:
I can work up a patch if you let me know which you prefer:
1.) Take it out completely
2.) Make clearing the caches a default operation, but add an option to disable it.
3.) Make NOT clearing the caches default, but add an option TO clear the cache.
4.) Investigate a drush_invoke('cc all') to see if that allows us to isolate the exceptions.
5.) Investigate try/catch.
Comment #5
q0rban CreditAttribution: q0rban commentedOr:
6.) Using drush_confirm, provide the user an option to clear the caches during drush rr.
Comment #6
q0rban CreditAttribution: q0rban commentedThe patch in #1299116: Utilize drush API properly solves this issue. I can separate it out into two separate patches, but it is somewhat related, so I threw it in there. I went with option 6.
Also, I just saw apotek's patch in #2. Whoops. That patch looks good. If you prefer that, I will refactor the patch in 1299116.
Comment #7
q0rban CreditAttribution: q0rban commentedapotek said:
Apotek and chatted on IRC about this, and while one could do a
drush rr -n
to use it in a command sequence, it's not very clear what you are saying "no" to. Instead, it would be clearer if there were an option to disable cache clearing. Working up a patch now.Comment #8
q0rban CreditAttribution: q0rban commentedComment #9
apotek CreditAttribution: apotek commentedThat looks good.
I would suggest not prompting for the user at all, ie, let it do it's thing…. especially since there's no option set for bypassing the prompt.
So, in my book, make it simpler, like
If there is an issue opened where someone needs a prompt, we can consider it then.
Comment #10
q0rban CreditAttribution: q0rban commentedThanks for the feedback, apotek. Committed!
http://drupalcode.org/project/registry_rebuild.git/commit/aefe70d
Comment #11.0
(not verified) CreditAttribution: commentedtypo fix