Problem/Motivation
The current dump to is limited to running in Drupal 8 but with some tweaks it can actually be expanded to dump any database including d6 and d7. This allows us to deprecate and replace the d6/d7 dump scripts with a much more robust script. It also opens up the ability for this to replace the migrate script as a standard tool for building test fixtures. Bonus, you can even use it to make a wordpress test fixture.
Proposed resolution
Remove use of module handler in dump tool(It only added documentation, not functional code).
Push database arguments into options so they can be supplied at the command line.
Add import script so we can manually test scripts as well.
Remaining tasks
Discus, review, decide if scope is reasonable?
User interface changes
This doesn't actually change the current scripts other then the database options trickling in as extra features in the current dump script.
API changes
I don't think these classes would be considered "API" so none? The dump command was extremely limited in what it could do so it would not have been terribly useful to extend or use outside of the existing script.
Data model changes
None.
Additional note:
https://github.com/neclimdul/drupal/pull/2 has a commit history that might give some context to the changes in the patch.
Original Report
This is purely for manual testing. I recently couldn't debug a particular problem in simpletest for various reasons and wanted to manually see what was happening when a update was running so I wrote this script to manually import any of the database fixtures created with the /core/script/database_dump* scripts. It seemed like it might be useful to other people so here it is.
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | improve_and_generalize-2550291-25.patch | 36.9 KB | neclimdul |
| #25 | 2550291-25.interdiff.txt | 3.51 KB | neclimdul |
| #24 | improve_and_generalize-2550291-24.patch | 36.94 KB | neclimdul |
| #24 | 2550291-24.interdiff.txt | 6.08 KB | neclimdul |
| #19 | improve_and_generalize-2550291-19.patch | 36.47 KB | neclimdul |
Comments
Comment #2
neclimdulSo let me generalize this a bit. The current script is a bit wonky and has unneeded limitations that we can remove and make it really flexible.
https://github.com/neclimdul/drupal/pull/2 has a commit history that might give some context to the changes in the patch.
Comment #4
neclimdulLeaving this nw because even with this fix, its going to fail because of #2553661: KernelTestBase fails to set up FileCache
Comment #5
neclimdulComment #6
neclimduli don't know why it keeps droping my patches...
Comment #7
neclimdulmy goodness... 2 interdiffs? I'm done for today.
Comment #8
neclimdulreroll. lets see what testbot thinks.
Comment #9
phenaproximaFound some nits, but only one thing glaringly wrong. There needs to be a way to specify certain tables which only exist in D6 and D7 should be dumped schema-only. Maybe a --schema-only option?
Nit: Needs a period at the end.
No doc comment.
Nit: There's an extra line here.
Nit: s/ensure/Ensure
Why are we relying on a specific connection ID being defined? This at least needs a comment to explain.
Nit: There's an extra space before the closing parenthesis.
If we're removing the list of modules, we shouldn't say "It has the following modules installed" :)
Nit: There's an extra line.
Nit: Empty extra line.
strtr()? Why not sprintf()?
Comment #12
webchickThis allows us to remove massive WTF-ery from Migrate, so escalating to major.
Comment #13
neclimdul1) 2) 3) 4) 6) 8) 9) done.
5) yeah, the docs where in the docblock for the method and wrong. Fixed and moved to the relevant code.
7) Actually the whole template is wrong. References the hopefully deprecated file script and references Drupal 8 being in the file where the point of this is we could dump anything from Drupal 6 to Wordpress.
10) sprintf uses %s and strtr lets me do @table which is more clear? I don't know I think I copied it from somewhere...
Note: leaving NW because #2553661: KernelTestBase fails to set up FileCache still blocks the tests.
Comment #14
neclimdulOh hey, forgot to send this to testbot.
Comment #15
phenaproximaPending DrupalCI's OK for SQLite and PostgreSQL, I approve. This beats the tar out of migrate-db.sh.
Comment #16
phenaproximaDammit! I have kick this back to NW because of something we still need. To quote myself in #9:
This would give the tool parity with migrate-db.sh, and thus we'll be able to remove it quickly and painlessly :)
Comment #17
neclimdulNow with even more tests (and some bug fixes... test coverage is good)
Comment #19
neclimdulthat regex_quote broke wildcards. another test.
Comment #20
neclimdulPatch is actually working. Sqlite adds a '.' to the end of the prefix in the constructor so the test is failing to confirm that the prefix is the value supplied... because its different. :(
Comment #22
neclimdullets try this.
Comment #23
phenaproximaFound a lot of nits, but nothing functionally wrong!
s/Can not/Cannot. Fixable on commit.
Why use preg_replace() here? What's wrong with preg_match()?
$connection needs a proper doc comment :)
$script should be specify that it's the path to a dump file script, not a string of PHP code to be executed.
Why @return mixed? As far as I can tell, this method returns nothing.
This is repeated throughout the test, can it be a protected property created in setUp()?
Nit: s/MySql/MySQL
I can't tell what exactly this is testing. It would benefit enormously from an explanatory comment.
Same here.
Comment #24
neclimdul1) Done
2) Because preg_replace lets you replace and array of values(all the schema only table matches), preg_match would require a loop.
3) Done
4) Well, both the command and tester are commonly used through out the test so i'm not sure that's useful and would just add a lot of text.
5) done
6) 7) done. also improved assert message a little.
Comment #25
neclimdulBetter assertion, thanks for calling that out in IRC phena.
Comment #26
phenaproximaDrupalCI approves! This patch makes me starry-eyed and sets my heart a-flutter. Totally, unabashedly RTBC.
Comment #31
neclimduloh pifr... i'm going to miss you... sort of.
Comment #32
webchickThis looks really awesome. I'll admit I didn't do a line-by-line comparison with migrate-db.sh but there's not a lot to complain about in this patch.
My one concern with this patch is it doesn't also remove migrate-db.sh. Which means if that doesn't get done by Sunday/Monday, we're at risk of shipping RC1 / 8.0.0 with both scripts, which is pretty silly.
Adam explained that this is because the patch to remove migrate-db.sh also needs to re-generate all the dumps and that's going to be an 11,000 GB patch so best to do on its own. That makes sense, but if folks could try really hard to get this done over the next 24-48 hours, it would be very much appreciated.
Committed and pushed to 8.0.x. Thanks!