Sorry for the unrelated lines at top of this patch

I am looking for an even faster way to save database dumps. The attached patch enhances sql-dump such that when --result-file is passed without a value, then drush generates a date based filename and stores the dump in the backups directory (i.e. the one that updatecode uses).

I'd like some feedback on this.

  1. An alternative is to save according to %dump in the site alias if defined. Not exactly sure how that should work.
  2. Another alternative is to keep current code but add an entry for result-file into examples/drush.php which does date based dynamic generation of filename.
CommentFileSizeAuthor
#1 dumpfile-2.patch3.54 KBgreg.1.anderson
dumpfile.patch2.45 KBmoshe weitzman

Comments

greg.1.anderson’s picture

greg.1.anderson commented
Status: Active » Needs review
StatusFileSize
new dumpfile-2.patch3.54 KB

Postgres users need love too.

I don't think that we should mix %dump and --result-file. These options can each be set separately; if the user wants them to go to the same location, they can set both values to point to the same place.

Rather than #2, I put in a simple str_replace so that drushrc.php could remain simple and still use date-based dump dirs if desired. Sure, you could drop in the current date with some php code in drushrc.php, but you couldn't substitute in the database name...

Anyway, I like the concept.

luchochs’s picture

luchochs commented

Not tested, but is a good idea/proposal.

luchochs’s picture

luchochs commented 
+++ examples/example.drushrc.php	30 Nov 2010 19:11:57 -0000
@@ -75,6 +75,18 @@
+# $options['result-file'] = TRUE;

$options['result-file'] = 'use-backup-dir'; might be a better option, I think.

Update: 'use-backup-dir' instead of 'backup-dir'.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Reviewed & tested by the community

@luchochs - you suggest to treat the string backup-dir as a pointer to updatecode's backup directory? i think TRUE is slightly clearer, IMO. RTBC I think. Nice improvement.

luchochs’s picture

luchochs commented

Productive exchange of ideas.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Reviewed & tested by the community » Fixed

Committed.

moshe weitzman’s picture

moshe weitzman commented
Status: Fixed » Active

I should really test better. Our command looks great mysqldump --result-file /Users/mw/.drush-backups/20101201115643/modules/wef_20101201_115643.sql

But mysql is won't create that dynamic directory name for us. So, 

mysqldump: Can't create/write to file '/Users/mw/.drush-backups/20101201115500/modules/wef_20101201_115500.sql' (Errcode: 2)

I think $this->prepare_backup_dir() needs to create the dir unless we are in simulate mode.

postgress uses >> to write to filesystem. Maybe mysql should do that too? Long ago I got some some unspecific advice that this was less reliable than --result-file due to charset issues. Is this possible?

greg.1.anderson’s picture

greg.1.anderson commented
Priority: Normal » Major

I'll clean this up. I think that postgres should use --file=...

I can't think of a good reason why >> should have any issue with charsets. I remember that you told me once that pipes took more memory than using intermediate files, but I never independently confirmed this, nor do I know whether >> is, on a low level, any different than a pipe. Conventional wisdom is that there should be no difference between using temp files and memory on Unix, but in practice it could be important on hosting services with little available RAM.

luchochs’s picture

luchochs commented
Category: feature » bug

This code was committed, therefore is a bug now.

moshe weitzman’s picture

moshe weitzman commented
Assigned: moshe weitzman » greg.1.anderson
jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented

@moshe I've fixed in #987064: Store backups in a better subdirectory a bug introduced in your previous change to backup.inc: it was not creating the $date/modules directory and also it was not calling prepare_backup_dir() but prepare_back_dir().

So #7 is fixed. Not tested for pg but I expect it also works.

I suppose this is what you want: /home/jonhattan/.drush-backups/20101202133339/d15_20101202_013340.sql

Also it would be nice to printout the location of the dump.

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Fixed

A bit awkward but done nevertheless.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.