Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
I'd like to see a sql-create command being added.
I've already done it as separate command, based upon the code existing for sql-sync as suggested over at http://groups.drupal.org/node/57073. I've attached the command file. If that works for you, we could roll a patch to add this to the sql.drush.inc file.
Setting to needs review although no patch yet, so we can get feedback on it first.
Comment | File | Size | Author |
---|---|---|---|
#9 | 0001-Issue-1627252-by-ao2-fago-Add-a-sql-create-command-2.patch | 3.87 KB | ao2 |
#6 | 0001-Issue-1627252-by-ao2-fago-Add-a-sql-create-command.patch | 2.74 KB | ao2 |
create.drush.inc | 3.7 KB | fago |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedI don't see enough broad beed for this. Please list a couple common use cases if you want this in core drush.
Comment #2
greg.1.anderson CreditAttribution: greg.1.anderson commentedsql-create has been rejected in the past, but I hope it can be accepted now, because I think this would be really useful. To create an sql database, I literally run the drush sql-sync command in simulate mode, and then copy the create db output to the command prompt. I've been meaning to revisit this issue for some time now; thank you for submitting this.
You might want to wait until @moshe weighs in before implementing the suggestions below, although my suggestions are fairly trivial.
1. It would be better if sql-create was part of the sql.drush.inc commandfile. Put the command definition there, at least; the implementation may be in its own file using the same technique as used in sql-sync, if desired.
2. Right now,
drush sql-create @site
works, but to use sql-create on the bootstrapped site you must usedrush sql-create @self
. For consistency, it would be good to supportdrush sql-create
/drush @site sql-create
by making a missing destination parameter default to '@self'. (function drush_create_sql_create_init($destination = '@self')
.Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedOK, we can proceed with Greg's suggestions and move toward bringing this in.
Not sure all those options make sense in this command. The comments mention --create-db when that isn't even a valid option.
Needs tests.
Comment #4
fagoThe posted command file already defaults to @self.
Yep, that --create-db is a left-over and needs to be re-used. The command options should make sense though as I've removed all not applying ones already? Which one do you think don't apply?
That's the plan. I just wanted to check out whether the command is welcome first :-)
Comment #5
ao2 CreditAttribution: ao2 commentedHi, I am interested in this too, I think it is useful especially for test setups.
Some comments:
In my use case I add a new user for each new drupal database I create, with a script like this:
maybe options to create users can be added too to this command, or would a new command sql-grant-user be better? What do you think?
What about adding a delete (i.e.
DROP DATABASE dbname
) command for symmetry? Or extend the currentsql-drop
to remove the whole database.Thanks,
Antonio
Comment #6
ao2 CreditAttribution: ao2 commentedOK, a tentative patch attached.
I am using
drush_sql_empty_db
which does what we want already. I tried to make the command looks like the other ones already defined. Let me know if there is anything left. I didn't use an external file as the callback is quite short.I think the aliases are handled by some common
_init
code, right? I tested and they work.The patch was created with
git format-patch
, so you can usegit am
to import it (this way I'll show up as the author in the git history).@fago is it OK to you that I am taking over?
Thanks,
Antonio
Comment #7
greg.1.anderson CreditAttribution: greg.1.anderson commentedThere is no guarentee that drush_sql_empty_db will necessarily use the technique of creating the database to perform its function; that is an implementation detail that might change in the future, or be implemented differently for some future database. If you want to share code between drush_sql_empty_db and drush_sql_create, factor the common code out into a separate function with clearly-defined behavior. In other words, it is okay for sql_empty to call sql_create, but not the other way around.
Comment #8
ao2 CreditAttribution: ao2 commented@greg.1.anderson, thanks, I'll factor out a
_drush_sql_create()
and send an updated patch.Comment #9
ao2 CreditAttribution: ao2 commentedPatch updated as per comments in #7.
Changelog since version1:
_drush_sql_create()
function in order to share some code withdrush_sql_empty_db()
drush_sql_create()
, the command does not acceptarguments, only options.
Comment #10
greg.1.anderson CreditAttribution: greg.1.anderson commentedNice; works great, and current tests pass. I like it, but perhaps should have at least one test.
Comment #11
fago>@fago is it OK to you that I am taking over?
Sure, thanks for caring! :)
Comment #12
ao2 CreditAttribution: ao2 commented@greg.1.anderson I'll try adding a test in version 3, but maybe we need a way to drop the database too? So the test does not leave traces of the created database?
what about a
--delete-database
or--drop-database
option to thedrush sql-drop
command?I am also thinking about factoring out the
db-su
options as they are used by more than one command.Comment #13
greg.1.anderson CreditAttribution: greg.1.anderson commentedI think I would favor a separate sql-delete command to delete databases. Extra factoring, where it makes sense, is a good idea.
Comment #14
ao2 CreditAttribution: ao2 commentedI see, I'll give the "sql-delete" way a try.
BTW in the create command, should I handle the sqlite case explicitly?
AFAICS databases are not created with SQL in sqlite, but the file gets created when it is opened the first time, right? The current code will just perform a void query with sqlite.
Comment #15
greg.1.anderson CreditAttribution: greg.1.anderson commentedIt does not look like you need to explicitly create tables in sqlite. http://www.sqlite.org/sqlite.html
Thanks for improving this further; adjusting status, since work still in progress.
Comment #16
dergachev CreditAttribution: dergachev commentedSeems to work great, thanks.
FY, in case anyone else is confused, the patch in #9 was actually committed to HEAD on July 10:
http://drupalcode.org/project/drush.git/commitdiff/7f67114993e26acc83586...
Comment #17
greg.1.anderson CreditAttribution: greg.1.anderson commentedYes, #9 was committed. Just setting status here to fixed to avoid further confusion; other suggested improvements can be done in a separate issue if someone comes back to pick them up.
Comment #18.0
(not verified) CreditAttribution: commentedfixed sentence