Utilize drush API
ceardach - March 9, 2008 - 01:04
| Project: | Database Scripts |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
See if it's possible to make this an add-on for drush and use it's API.
#1
Any update on this?
#2
Not yet, but I still want to do it. Now that Drush has been moved to be independent of a Drupal install, it is absolutely ideal.
I'm going to finish my port to D6, then take a stab at this.
#3
Nice to hear! With dbscripts using the Drush API this great module might be adopted much more easily than now. For example, I had some hard time configuring it because of the settings and the fact you can only run it in one place if you have the settings specified relatively.
I might take a stab at this as well, imagine to tell at Drupalcon that now dbscripts is part of the drush suite.. :)
#4
oh boy, can't say at Drupalcon that the Drush integration is complete :) I'm working at saying that D6 upgrade is complete!! I am doing a presentation as part of the Deployment session, so I damn well gotta have a D6 upgrade by then. My schedule is to have the D6 upgrade done by Feb 15 (and I just took on a new client...), so I have two weeks to create my presentation. With that schedule, I'll have no time for the Drush integration :(
However, Patterns is having a presentation. They have a D6 development version currently (which I haven't tested). If they have it working, as described during the BoF last year, this entire project is moot. It will completely change the concept of Drupal development as we know it.
#5
On a side note, please let me know about your issues with configuration settings in another issue. I would like to know where it fails so I can possibly improve it.
#6
Thanks for pointing me out to patterns, it seems like something all of us could benefit from.
Regarding dbscripts, we are thinking to have the development database dump hook up into the svn commit of our local developers. This way, we would have a complete snapshot of the state of the website (files + database) at any point under svn (similar to drush API where you can have your updated modules commit directly to svn). Any comments on this?
#7
That is exactly how I envision it's use.
#8
In order to allow me to keep my settings php file in svn, my settings.php file uses the environment to determine the correct settings to use. eg:
<?phpif ($_SERVER['HTTP_HOST'] == 'www.mydomain.com' || $_SERVER['HTTP_HOST'] == 'mydomain.com') {
// On the LIVE site, where the database is located on db2
$db_url['default'] = 'mysql://myuser:mypassword@192.168.1.91:3306/concern_drupal';
$db_url['civicrm'] = 'mysql://myuser:mypassword@192.168.1.91:3306/concern_civicrm?new_link=true';
}
elseif ($_SERVER['HTTP_HOST'] == 'stage.mydomain.com' ) {
// On the STAGE site, where the database is local
$db_url['default'] = 'mysql://myuser:mypassword@127.0.0.1:3307/concern_drupal';
$db_url['civicrm'] = 'mysql://myuser:mypassword@127.0.0.1:3307/concern_civicrm?new_link=true';
}
elseif ($_SERVER['HTTP_HOST'] == 'dev.mydomain.com' ) {
// On the DEV site, where the database is local
$db_url['default'] = 'mysql://myuser:mypassword@127.0.0.1:3306/concern_drupal';
$db_url['civicrm'] = 'mysql://myuser:mypassword@127.0.0.1:3306/concern_civicrm?new_link=true';
}
?>
So dbscripts is unable to find the connection information. I'm posting this here, since drush can find the correct settings to use, presumably due to the fact that I pass it the -l flag to let it know which host I want to run it against. I'm guessing that if dbscripts was a part of/extension to drush, then it wouldn't have this problem.
ps. I already applied the patch at http://drupal.org/node/281313 to allow $db_url to be an array.
#9
Thanks, I've been meaning to address #281313: Connection to database when multiple URLs are defined, and you are correct that Drush integration would make this easier.
I haven't encountered your particular problem because I do not keep settings.php in version control. Instead I make it settings.php.example and copy the file to settings.php, and make changes to it, when setting up a new environment. If you have multiple developers, and consequently multiple development environments, using that method would be handy.
#10
#11
***First Draft***
I created a dbscripts.drush.inc which implements the drush API for this module. I also had to move some of the code in the command files (erase.php, find.php, raise_increments.php) into new functions in dbscripts.module.
Once you apply the patch the scripts *should* still work exactly as they did before. Then once you move the dbscripts directory into your ~/.drush directory (standard procedure for drush extensions that live outside of the drupal installation), you can also call them from drush.
You can see the list of commands with: drush help
For detailed info on the option: drush help dbscripts [command]
TODO: Test, etc. and port the help documentation