Posted by ceardach on March 9, 2008 at 1:04am
| Project: | Database Scripts |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
See if it's possible to make this an add-on for drush and use it's API.
Comments
#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
#12
Has this been tested for multiple install; this is going to have issues for anyone that has multiple using of dbscripts since they may need multiple configuration files for different needs I believe?
#13
Thanks for the patch, I was a bit tired last night so likely came off as rude.
Right now I'm trying to address the db scripts bugs so this is on lower priority.
But as far as the config, it seems like it would be best if there was a way, probably best through an option -c=/var/www/blah/ to address or/and through a drushrc config where the config file is stored since there need to be able to be configurable per install. Perhaps the general location of the dbscripts.module file could also use a configuration option.
Also, it looks like it will still work as it was previous working, correct? To me that is important; I have no urges to install drush on live sites when it really is not needed. Perhaps the drush location of dbscripts.module should also be configurable if it's not already.
Anyhow, right now my main focus again on bugs fixes (user fix and auto complete), so dev will be changing. I am interesting in getting in the moving most of the standalone files to the dbscripts.module first, so that patch would be great (but may want to wait a few days).
(CVS is more update then git atm, but I'm going talk to kathleen tonight to figure out how to update github with branching done correctly).
If you're not interested in this anymore, then I'll likely get to it... eventually.
#14
Regarding configs... a -c option would be great. Not only do you need to be able to be configurable per install, but it should be made possible to use multiple configs per install. I use this to backup/sync both the Drupal database and the CiviCRM database. To do this, I have two dbscripts configs, and use my Makefile to switch them around:
A small excerpt from one of my Makefiles to show you what I mean
#-------------------------------------------------------------------------------
# dump/restore the PRODUCTION version of Drupal
drupal-dump-production:
cp dbscripts/config.inc.drupal dbscripts/config.inc
dbscripts/dump.php production min
drupal-restore-production:
cp dbscripts/config.inc.drupal dbscripts/config.inc
dbscripts/restore.php production min
#-------------------------------------------------------------------------------
# dump/restore the PRODUCTION version of CiviCRM
civicrm-dump-production:
cp dbscripts/config.inc.civicrm dbscripts/config.inc
dbscripts/dump.php production min
cp dbscripts/config.inc.drupal dbscripts/config.inc
civicrm-restore-production:
mysql -h ${CIVICRM_DB_HOST} -u ${ROOT_DB_USER} -p${ROOT_DB_PASSWORD} --execute="DROP DATABASE IF EXISTS ${CIVICRM_DB}; CREATE DATABASE ${CIVICRM_DB}; GRANT ALL ON ${CIVICRM_DB}.* TO '${DB_USER}'@'localhost' IDENTIFIED BY '${DB_PASSWORD}'"
cp dbscripts/config.inc.civicrm dbscripts/config.inc
dbscripts/restore.php production none
cp dbscripts/config.inc.drupal dbscripts/config.inc
mysql -h ${CIVICRM_DB_HOST} -u ${ROOT_DB_USER} -p${ROOT_DB_PASSWORD} ${CIVICRM_DB} --execute="TRUNCATE civicrm_cache; TRUNCATE civicrm_log; TRUNCATE civicrm_acl_cache;"
sudo rm -f ${SITE_ROOT}/files/civicrm/upload/Config.IDS.ini
drush script scripts/reinit_civicrm_config.php
sudo rm -rf ${SITE_ROOT}/files/civicrm/templates_c/*
Would be nice if I could call dbscripts with a -c option to specify which config it should use...
#15
To keep track then the 3 changes are
1) Reorganize dbscripts.module so all functions are in a shared file
2) Add a -c option to specify which config file to use (overrides default)
3) Add drush stuff
4) Add ability for -c/drushrc into the drush implementation
I'll look into -c first probably despite that order; if someone else wants to repatch 1), 3) and 4) separately that'd be grand (but again, may want to wait a few days till the bug fixing has been done).
#16
mrfelton whenver the dev release gets updated could you try out dump using the -fc==path/to/configure.inc (after the dump info, ie ./dbscripts production -fc==path/to/configure)
Also you include the corresponding config.references file if it differs via -fr==path/to/reference or $reference_file in the configure file (I hope) (haven't tested much).
This has only been done for dump.php at this point.
#17
Moved find and some other code into dbscripts.module and changed a lot of how options are handled (basically for just send in the argv resorted so it'd begins where it would if didn't need the extra space to say drush
#18
One of the benefits of this would be that Drush figures out making it work for Drupal 6 and 7...
#19
Any updates on this?
Thanks,
-Kelly Bell