This primary purpose of this patch is to add hook_demo_dump_alter() for other modules, to allow them to alter the list of tables before they are dumped. This required to move the database tables list to demo_dump_form, and changing several functions to behave more API-like (which is A Good Thing™).
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 535754-demo_dump_alter.patch | 16.36 KB | smk-ka |
| demo_dump_alter.patch | 16.63 KB | smk-ka |
Comments
Comment #1
sunNice catch! But actually, D7 (HEAD) changed the coding standards for PHPDoc summaries to be in the third person form, as in "Returns foo bar.". :-/
So we might want to revert this change.
If I wouldn't know what we are doing here and why, I would not grok why $output is entirely reset in a loop here. That could use a comment.
Hmmm... We should move those changes to a separate issue, I think.
...oh, scratch that, I see now that it's required for the other changes.
Ideally, consistently use "Menu callback; Display snapshot selection form."
Do we still need this?
oh, nice! This could finally solve the "cron not always resetting" issue! :)
...shouldn't we use time() here?
...hrm, thinking twice about that, it might as well break cron runs again, because demo_cron() calculates the difference to the last cron run. :-/
Why aren't we using module_load_include() here?
This review is powered by Dreditor
Comment #2
smk-ka commentedRerolled with sun's suggestions, except:
This looks wrong: a sentence continues lowercase after a semicolon. Core doesn't seem to have a clear rule either, but continues most frequently with a lowercase word.
Yes, as long as DROP TABLE is not moved to the SQL dump we still need to drop tables before restoring.
No, time() would be the current time which can be different on each invocation (depending on the number of cron implementations that ran before). $_SERVER['REQUEST_TIME'], on the other hand, is always the time when the request started, which is much closer to how the system crontab works. The mixing of time() and $_SERVER['REQUEST_TIME'] before could have been the cause for miscalculations.
Comment #3
sunThanks for reporting, reviewing, and testing! Committed to all branches.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.