Drush integration for demo module

Thank you, @sivaji; this looks great! I've tested it with the latest dev release. Here are my findings/thoughts:

1. There's a typo and a small grammatical error in the reset warning message: "WE RECOMMEND YOU TO HAVE A BACKUP OF YOUR DATABASE". I've corrected them and attached a new patch.
2. All the major functionality works great. (And it seems fast, compared to Backup and Migrate!) Creating a snapshot through the web interface and through Drush resulted in backups of the same file size, which is good. Error handling for missing arguments and such is good.
3. I noticed you can execute the commands from Drush even if the module's not enabled on the site. (I successfully used demo-create.) I don't know if it should be that way or not.
4. I wonder if demo-snapshots should sort the snapshots by date the way the web interface does?
5. There should probably be a drush_confirm when deleting a snapshot.

Thanks again, @sivaji! :)

Oops. One more thing: It looks like if none of your snapshots have any description, it mucks up the table headings in the output of demo-snapshots:

 Fi                         Da                  Si         Des
 le                         te                  ze         cri
 na                                                        pti
 me                                                        on
 Fresh-Drupal-6.14-Install  11/28/2009 - 10:58  211.82 KB  n/a
 Tuned-Workspace            03/20/2010 - 12:44  228.22 KB  n/a
 Fresh-Drupal-6.15-Upgrade  02/23/2010 - 15:45  186.48 KB  n/a
 Fresh-Drupal-6.16-Upgrade  03/05/2010 - 18:19  198.57 KB  n/a

If I simply add a snapshot with a description, I get this:

 File name                  Date                Size       Description
 Test                       04/10/2010 - 17:47  228.42 KB  This is an example test message
 Fresh-Drupal-6.14-Install  11/28/2009 - 10:58  211.82 KB  n/a
 Tuned-Workspace            03/20/2010 - 12:44  228.22 KB  n/a
 Fresh-Drupal-6.15-Upgrade  02/23/2010 - 15:45  186.48 KB  n/a
 Fresh-Drupal-6.16-Upgrade  03/05/2010 - 18:19  198.57 KB  n/a

Also, could we shorten demo-snapshotsto, say, demo-list? It's less to type, and I for one find it much easier to remember. (I have to stop and think every time to remember "snapshots".) If not, perhaps we could get a shorthand version of it.

Speaking of which, perhaps we should add a command alias for demo-delete, such as demo-del, in keeping with the precedent set by Drush core (e.g. variable-delete (vdel) and watchdog-delete (wd-del)).

Finally, I wonder if there would be value in adding, say, a demo-info command to get more detail on a particular snapshot (namely, a list of the modules installed, as you would find on the web interface) similar to pm-info for modules. Hopefully that's the last thought I'll have on this tonight. :)

I compared the contents of a snapshot created through the web interface with those of one created with Drush, and they were identical except for a little session data, which is to be expected. So it looks like we're good on that front.

Your changes look great! I like how your first two command aliases (demo-mk and demo-rm) mirror corresponding Linux commands. That was smart. Unless the other three also mirror common commands I'm unfamiliar with (I'm a bit of a Linux n00b) I'd personally just omit them and suggest demo-list as an alias for demo-snapshots, but as you're the one doing all the work here, I happily defer to your judgment. :)

I also proofread all the messages in the code and corrected a dozen or so typos and grammatical errors and made small changes to wording to maintain consistency with core Drush messages (mostly changing verb tenses). I also deleted a TODO that had been completed. Here's a new patch.

Uh-oh. Suddenly demo-delete isn't working for me, but I'm getting a PHP error instead of a Drush message:

# drush demo-mk test
Successfully created snapshot sites/all/files/demo/test.sql                                                                                          [ok]
# drush demo-rm test -y
This command will delete the snapshot and can not be undone                                                                                          [warning]
Are you sure you want to continue? (y/n): y
WD php: unlink(): No such file or directory in /home/bigfatug/public_html/test/sites/all/modules/contrib/demo/demo.drush.inc on line 178.            [error]
WD php: unlink(): No such file or directory in /home/bigfatug/public_html/test/sites/all/modules/contrib/demo/demo.drush.inc on line 179.            [error]
Deleted snapshot test                                                                                                                                [success]

Is it still working for you, @sivaji? I don't think I changed anything that should have broken it, but I don't have time to test further tonight.

Good thinking with demo-ls; I like it. demo-delete works again.

I've been looking at drush_print_table and drush_table_column_autowidth to see if I could identify the problem reported in comment #4 as belonging to Drush core, and I can't replicate the issue with any other commands. On the other hand, if I comment out line 197 of demo.drush.inc, I don't have the problem with demo-snapshots anymore, either.

// Line 197:
$rows[time()] = array('File name', 'Date', 'Size', 'Description');

Does that suggest anything to you, @sivaji? I can't see what could be wrong with demo.drush.inc, but I can't seem to "break" anything else.

I'm not entirely sure I understand the request, @winston. Your thought is that demo-update would detect which snapshot the current state of the site reflected? In other words, it would compare your site with your snapshots and say, "This is the snapshot that your current site is based on". My first thought is that that isn't really feasible because the live database will have changed from the snapshot, even if only with respect to the sessions and logs. There are perhaps a few ways it could be basically accomplished, but those that I can think of would be either extremely complicated and resource-intensive or hacky. In short, it would involve the addition, not merely of a Drush interface, but a whole new feature to Demo module itself; for which reason I would encourage you, if you wish to pursue it, to open a separate feature request issue. As to your plan to create a script to loop through snapshots applying them, you should only need to apply the latest one, because each snapshot is a complete export of the database and stands alone. Applying several serially will have the exact same effect as just applying the last one. Best wishes!

@auzigog: Thanks for asking! You could test the patch in #9 and give your feedback. We've only had two eyes on it so far. Also, there's a bit of a rendering issue described in #4 and #11 that you could help us diagnose—or at least confirm it still exists. That would be a big help!

@winston: I still don't understand the need to loop through a set of snapshots, because snapshots aren't cumulative. Each one is a full database dump. If you apply one from yesterday, drush up, and then apply one from today, whatever changes were made to the database via drush up will be overwritten and lost when you apply the second snapshot. You'll have to drush up. Just applying the very latest snapshot and doing a drush up would have the same result (and, obviously, be much easier). If you still feel you need the functionality, please create a new support request. Thanks!