With a unprivileges mysql user:
$ drush @imc si
You are about to DROP your 'imc' database and then CREATE a new one. Do you want to continue? (y/n): y
ERROR 1044 (42000) at line 1: Access denied for user 'imc'@'localhost' to database 'imc'
No tables to drop.
if I pass --debug then mysql is invoked with -v and there's an extra failure because the sql query is included in the output:
jonhattan@jengibre:~$ mysql -v imc
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2367
Server version: 5.1.49-3 (Debian)
mysql> show tables;
--------------
show tables
--------------
Empty set (0.00 sec)
so it will do
Calling db_query(DROP TABLE SHOW TABLES, --------------, )
also in this case for --debug we obtain an extra bug:
call_user_func_array() expects parameter 1 to be a valid callback, function 'db_query' not found or invalid [warning]
function name drush.inc:1159 [2.48 sec, 7.35 MB]
It seems db_query is not available in DRUSH_BOOTSTRAP_DRUPAL_SITE stage.
other thing I'm seeing is that drush @alias si doesn't work, because of @alias. It doesn't mather the cwd. I've also tried using drush_shell_cd_and_exec() in site_install_6.inc with no luck.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | drush-1018936.patch | 3.17 KB | jonhattan |
| #16 | si-mixedCase.patch | 1.85 KB | jonhattan |
| #11 | drush-1018936.patch | 1020 bytes | jonhattan |
| #8 | drush-1018936.patch | 1.03 KB | jonhattan |
Comments
Comment #1
jonhattanI'll try to reorganize above report:
1/ drush @alias si doesn't work *for d6* because of the alias (it doesn't matter the cwd --in $drupal_root or out). I've succesfully run the same command for d7.
2/ mysql -v is inadequate if you plan to parse its result.
3/ db_query() is called by drush_sql_drop() and is not available before DRUSH_BOOTSTRAP_DRUPAL_DATABASE
Comment #2
greg.1.anderson commentedI'm not going to have time to work on this today after all. :(
I'll be back online Sunday night. Ship drush-4 w/out this or wait for me or do this for me -- any is okay with me.
My thoughts:
1. Don't know why
2. We should add drush_get_option('sql-verbose') and not make sql produce verbose output just because -v is on. This should be passed as a param to sql execute, so functions that call sql query programatically can have 'verbose' turned off.
3. We should be able to call sql-drop via backend invoke so that it will bootstrap to the DATABASE level.
Comment #3
moshe weitzman commented2. sounds good.
3. Lets take a little more time to do what we originally wanted which is to make sql-drop work without any bootstrap.
Comment #4
moshe weitzman commented2. I just fixed this by removing verbose from mysql and postgres calls. It didn't actually help us.
Comment #5
moshe weitzman commented1. I can't reproduce this. I just tried on another local site. Are you using a remote site? Are you sure that its drush is up to date? Please post a full --debug log.
Comment #6
moshe weitzman commented3. Fixed. Now using _drush_sql_query() instead of db_query().
Comment #7
moshe weitzman commentedI should note that I didn't implement my suggestion to make sql-drop a pure bash operation since thats a bigger change that we should do in Drush 5.
At this point, we need confirmation that the alias technique works or fails. after these changes. And a full debug log.
Comment #8
jonhattanMy alias is:
and the original site was installed at sites/default. There's no multisite environment. So I run
drush @imc si.The first chunk of code to be run through
php -rin site_install_6.inc is:The difference when running
sifrom the drupal root is that$_SERVER["HTTP_HOST"] = "http://imc"is always the same as --sites-subdir, and without http://.Attached a patch that fix this situation and doesn't seem to break other scenarios.
btw here's the debug output:
Although it doesn't mark an error it doesn't install the site at all.
Comment #9
jonhattanComment #10
moshe weitzman commentedI could reproduce this problem but it is solved by passing --sites-subdir. That option is mandatory for new installs. I don't think we need the latest patch as it complicates site-install for existing sites (they would also be required to pass --sites-subdir).
Please confirm that passing --sites-subdir fixes the problem. If desired, you may put it into drushrc.
Comment #11
jonhattanThe problem here has introduced by me in #1004476: site-install doesn't work for d6 when installing in a subdir. HTTP_HOST should not include the protocol part. drupal_valid_http_host() in conf_init() was killing the installation process.
Comment #12
moshe weitzman commentedNice detective work.
Comment #13
moshe weitzman commentedcommitted. thanks.
Comment #15
moshe weitzman commentedI'm seeing a problem with the most recent fix here. If you use a mixed case name for your sites-subdir, it gets automatically lowercased when reading out of $_SERVER['HTTP_HOST']. Not sure if that always happens or just on some configurations of PHP. So, the HTTP_HOST that we set is wrong and Drupal tries to install to sites/default instead of sites/mixedCase (for example).
using
PHP 5.2.10-2ubuntu6.7 with Suhosin-Patch 0.9.7 (cli) (built: Jan 12 2011 17:56:07)Comment #16
jonhattanI'm not able to install a site at sites/mixedCase site even via web. mixedCase is supposed to be a domain name and they're case insensitive. I see my browser and apache lowercasing it.
With attached patch we force to assign mixedCase to HTTP_HOST, and also pass the failure to drupal internals. No possible fix IMO.
In the log:
....
Comment #17
moshe weitzman commentedOK. Feel free to commit the patch if you think it is helpful. Otherwise, lets move this back to fixed.
Comment #18
jonhattanThe patch is syntactically precise in the usage of 'uri' (by respecting http://) so commited. Also implemented a validation callback to force lowercase sites-subdir.
http://drupal.org/cvs?commit=495602
Comment #19
jonhattanBackport #18 worth it to reduce some possible bug reporting. Attached the complete patch.
Comment #20
msonnabaum commentedThanks jonhattan. Committed.
http://drupal.org/cvs?commit=496840