Posted by ceardach on March 12, 2009 at 4:19pm
| Project: | Database Scripts |
| Version: | 6.x-2.x-dev |
| Component: | Documentation |
| Category: | bug report |
| Priority: | normal |
| Assigned: | hefox |
| Status: | reviewed & tested by the community |
Issue Summary
To reduce the chance of losing valuable data during a restore, make a configurable option to dump the current state of the database before restoring.
Comments
#1
Maybe rely on backup_migrate for this one ? If this module is going to go into drush eventually you can hook into the {system} table and if backup_migrate is available just use its config (path, archive or not, etc) options to do a manual backup.
#2
Also could make a script that does a dump to a different name (new dumps can be made via doing ./dump , ie ./dump paranoia).
If you still use dbscripts and interesting in making a patch, I'd image a config variable named $paranoia_dump = 'name of where to dump', then in restore call dump with that name if it's set.
#3
Dbscripts should have this feature tonight whenever I get home (and should have some.. cvs oops fixed also).
It will be able to be set permently in config via setting the $paranoia variable or via using the option -par=, and can be supressed saying ./restore.php nopar
Ignore below; (I realllly don't feel like setting up work computer for dbscripts in cvs/git mess)
<?phpfunction dbscripts_restore($options) {
$options = _dbscripts_get_options($options,'restore');
require($options['configure_file']);
extract($options);
if (($options['paranoia'] || $paranoia ) && !$options['not_paranoid']) {
$fake_options[1] = $options['paranoia']? $options['paranoia'] : $paranoia ;
dbscripts_dump($fake_options);
}
?>
<?phpcase '-par=':
if ($end) $options['paranoia'] = trim($end,"=");
unset($argv[$k]);
break;
case 'nopar':
$options['not_paranoid'] = 1;
unset($argv[$k]);
break ;
?>
#4
http://drupalcode.org/viewvc/drupal/contributions/modules/dbscripts/dbsc...
#5
Automatically closed -- issue fixed for 2 weeks with no activity.
#6
This feature does not show up in the documentation - please add it so this is clear to users.
Also, if $paranoia=TRUE in config and the user runs ./restore.php, does the paranoia dump go into db/workspace/last-dump? If not, where does it go? Thanks!
#7
Enabling 'paranoia' appears to overwrite your dump files with your current database, thereby restoring your database to exactly how it was before you attempted a restore.
For instance:
After running
./dump.php development noneI changed the title of a node in my site (from 'Language' to 'Languagezzzz'). Then, I ran./restore.php development none. The expected behavior is that the title of the node I changed would return to what it was before I changed it (from 'Languagezzzz' to 'Language'). The actual behavior is that the node title stayed exactly the same ('Languagezzzz').I suspect the problem is that with paranoia set to true, you run a regular database dump before attempting to restore the database, thereby overwriting the original dump files. Perhaps there ought to be a separate folder for paranoia dumps?
#8
I created a patch that when executing a 'paranoid' dump, the dump script places the dumped files in $dump_path/paranoid_dump.
#9
When a patch needs review, it should be marked needs review to my understand; to be ported is for dealing with different verisons of a module, ie from a 7x to a 6x.
I think this actually might just been back to needs documentation
I'm not currently using dbscripts for any activate projects, and haven't been using $paranoia settings since creating it actually, but from what I remember the setting I added was actually suppose to contain the database name, ie $parnonia = 'dump_location'. Does that make sense? Assuming that this is still working, wouldn't that meet the needs of your patch?
http://drupalcode.org/viewvc/drupal/contributions/modules/dbscripts/dbsc...
It's possible some later code overwrote those settings.
My guess though that is setting it to a nonstrict resulted it in falling into some other location, but haven't looked into it X.x
#10
First, you are totally right! I don't know why I didn't realize that after going over the code, for some reason I just assumed $paranoia would be a boolean. Thanks for clearing that up - yes, this just needs documentation now.
Second, sorry about the wrong status setting, I'm new to patching for Drupal.
#11
hehe, no worries. Feeel free to make a patch for the documentation ( reason there's no documentation is that I'm horrid at documentation D:); and please test that it actually still works, it was added in with a lot of other changes!
#12
It does indeed still work - I still can't believe I didn't figure that out after going over the code...
Ok, patch attached to add documentation for 'paranoia'. Added it to help function for restore.php and added explanation in config.inc.example. By the way, this was patched against your git repository as of this morning.
#13
Cool, and thankyou!
Haven't tested but looks fine, so RTBCing it anyway and will add it soon