make db form settings

[Carl Karsten]

I have the begging of something that may eventually get submitted, and looking
for guidance as I build it.

In the spirit of DRY, I have a nifty script that helps create the db defined in
settings.py

#!/usr/bin/env python
# mkdbuser.py
# prints the CREATE DATABASE and GRANT commands based on the local settings.py

import settings

SQL = """
DROP DATABASE IF EXISTS %(db)s;
CREATE DATABASE %(db)s;
GRANT ALL
ON %(db)s.*
TO %(user)s
IDENTIFIED BY '%(pw)s'
with grant option;

"""

print SQL % {
'db':settings.DATABASE_NAME,
'user':settings.DATABASE_USER,
'pw':settings.DATABASE_PASSWORD }

# end: mkdbuser.py

I pipe it into the client:
$ ./mkdbuser.py | mysql -u root -p
and presto! I have the db that syncdb wants.

I am thinking it would be nice if it was hung off of db/backends/mysql so that
it was driven by DATABASE_ENGINE and the various backends could spit out the
appropriate dialect.

I am also researching exactly what rights are needed by syncdb and runserver or
any production use so that what is spit out isn't quite so wide open. If anyone
has already done this, I would rather not repeat it. :) however, if someone
wants me to anyway so we can compare notes to make sure we didn't mis anything,
thats fine too.

Carl K

[Max Battcher]

I'm not sure if there is a large enough need for your script, Carl K.
Creating the databases themselves should be a rare activity. Perhaps
you'd be better off looking for a deployment engine that supports what
you need, such as Capistrano.

--
--Max Battcher--
http://www.worldmaker.net/

[Adrian Holovaty]

On 7/4/07, Max Battcher <m...@worldmaker.net> wrote:
> I'm not sure if there is a large enough need for your script, Carl K.
> Creating the databases themselves should be a rare activity.

Agreed. One should only have to create a database once. It's dropping
and creating individual *tables* that can be repetitive.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

[Carl Karsten]

Adrian Holovaty wrote:
> On 7/4/07, Max Battcher <m...@worldmaker.net> wrote:
>> I'm not sure if there is a large enough need for your script, Carl K.
>> Creating the databases themselves should be a rare activity.
>
> Agreed. One should only have to create a database once. It's dropping
> and creating individual *tables* that can be repetitive.

kinda hard to create a database twice :)

seriously - as part of 'learning about django' I have dropped / created a db
about once a day for the last 2 weeks. and regardless of my personal habits,
consider the number of django insulations: each one needs the db created. why
not make it easier?

So far I have only heard reasons why it isn't that important, but no reasons not
to.

Personally I think once I get the rights thing figured out, it will help create
more secure installs.

So is this still something I should not bother submitting?

Carl K

[James Bennett]

On 7/5/07, Carl Karsten <ca...@personnelware.com> wrote:
> So far I have only heard reasons why it isn't that important, but no reasons not
> to.

I'm cautiously skeptical. Probably the best route to take with
something like this would be to develop and release it as a standalone
utility; this lets you do several important things that are much
harder to manage when it's simply a patch sitting in Trac:

1. It lets you see how many people are interested in using it.
2. It lets you get feedback on how they use it.
3. It gives you an easy way to respond to feedback and update the code.

All of these also are generally good indicators that something should
be included in Django ;)

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[Nis Jørgensen]

Carl Karsten skrev:

> I have the begging of something that may eventually get submitted, and looking
> for guidance as I build it.
>
> In the spirit of DRY, I have a nifty script that helps create the db defined in
> settings.py
>

[snip]

> I am thinking it would be nice if it was hung off of db/backends/mysql so that
> it was driven by DATABASE_ENGINE and the various backends could spit out the
> appropriate dialect.
>

+1, I would use this. Also, don't we have this almost implemented for
creating the test database?

Nis

[Russell Keith-Magee]

Yes, but this technique relies upon being able to log into the normal
database so as to make the CREATE DATABASE call as a native SQL
request. You need to be able to log into a database (any database) to
create another. This won't work for boostrapping the original
database, unless you modify the Django setup to include settings for
accessing the management database for each supported backend.

For the record, I'm -1 to the idea. As Adrian has noted, database
creation should be a relatively infrequent activity. Dropping/Creating
a database isn't that difficult to do manually, and warrants being a
_little bit_ difficult so as to make it difficult to accidentally drop
a database with all the data in it (ie., you have to mentally swap to
a 'database destruction mode' to do it, rather than just running
another ./manage.py command).

Yours,
Russ Magee %-)

[Carl Karsten]

Russell Keith-Magee wrote:
> On 7/5/07, Nis Jørgensen <n...@superlativ.dk> wrote:
>> Carl Karsten skrev:
>>> I have the begging of something that may eventually get submitted, and looking
>>> for guidance as I build it.
>>>
>>> In the spirit of DRY, I have a nifty script that helps create the db defined in
>>> settings.py
>>>
>> [snip]
>>> I am thinking it would be nice if it was hung off of db/backends/mysql so that
>>> it was driven by DATABASE_ENGINE and the various backends could spit out the
>>> appropriate dialect.
>>>
>> +1, I would use this. Also, don't we have this almost implemented for
>> creating the test database?
>
> Yes, but this technique relies upon being able to log into the normal
> database so as to make the CREATE DATABASE call as a native SQL
> request. You need to be able to log into a database (any database) to
> create another. This won't work for boostrapping the original
> database, unless you modify the Django setup to include settings for
> accessing the management database for each supported backend.
>
> For the record, I'm -1 to the idea. As Adrian has noted, database
> creation should be a relatively infrequent activity. Dropping/Creating
> a database isn't that difficult to do manually,

What part of creating a web site is? This whole django thing is pretty
pointless. :)

> and warrants being a
> _little bit_ difficult so as to make it difficult to accidentally drop
> a database with all the data in it (ie., you have to mentally swap to
> a 'database destruction mode' to do it, rather than just running
> another ./manage.py command).

For that, I'll # out the DROP command.

Carl K

[Johan Bergström]

I recently made a patch that can be used to get a similar result.
You can find the patch here: http://code.djangoproject.com/ticket/4528

regards,
Johan Bergström