[Camps-users] [Camps-commits] [SCM] Camps development environments branch, master, updated. d09a96a609343a4789f494e99f660622ad7b7249

[Jon Jensen]

On Mon, 16 Mar 2009, Ron Phipps wrote:

> I'm working on migrating a client to a new server and as part of the 
> process I'm upgrading their camps library as well.  The issue I'm 
> running into is when running mkcamp the database is created, the roles 
> are created, but when the database is being imported I receive the 
> following error:
>
> Processing script 'mysql/tmp/frozencpu.sql':
> mysql -u root -p6nob83gu --socket=/home/ron/camp1/mysql/tmp/mysql.1.sock
> < /home/camp/frozencpu/mysql/tmp/frozencpu.sql
> ERROR 1046 (3D000) at line 12: No database selected
> Error importing data
>
> The problem is the patch above sets no_database => 1 which doesn't allow
> the db_default_database to be used when importing the production dump.
>
> Here is the relevant section to the local-config:
>
> db_dbnames:frozencpu
> db_mysql_scripts:mysql/tmp/frozencpu_init.sql
> db_source_scripts:mysql/tmp/frozencpu.sql
> db_default_database:frozencpu
> db_default_user:root
> db_sleep_time:15
>
> frozencpu_init.sql contains:
>
> CREATE DATABASE frozencpu;
>
> frozencpu.sql is the production dump.
>
> From my understanding this is the correct way to do a mysql based app. 
> The extra init script is needed because mysqldump does not include a 
> create database statement or a connect to the database.
>
> I'm not sure of the situation you ran into which requires no_database => 
> 1 so I cannot not submit a patch that works for both cases.  If you have 
> a scenario you'd like me to test I can work on a patch that works for 
> both scenarios.  For the time being I have removed the no database 
> option.

Sorry for the trouble. The camp system you're migrating was probably one 
of the earlier MySQL camps, and didn't follow the established Postgres 
convention. That's not uncommon for those early MySQL camps, because the 
conventions weren't always well-documented and we did so few of them in 
MySQL.

The problem Adam and I were fixing was that db_default_database/user is 
intended to say what database/user to connect to with the mysql_camp 
command -- not during initial database population. That should be 
specified in the dump script used for import. And it always has been for 
Postgres.

Adam ran into his trouble on one new MySQL camp system within one day of 
when I ran into it for another new MySQL camp system, and unless I'm 
forgetting something, that was the problem. Of course it could go either 
way, but the early convention was that the dump script is responsible for 
creating and connecting to the right database -- and our Postgres camps 
conventions usually win, since they're far more numerous. :)

The camp-dbdump script I used outputs the CREATE DATABASE and USE commands 
necessary for things to work with the patch you reverted:


#!/bin/sh

type=    # you set
dbname=  # you set
dbuser=  # you set
dumpfile=~camp/$type/mysql/dbdump/tmp/$dbname.sql
tmpfile=$dumpfile.$$
mysqldump -u $dbuser --databases $dbname > $tmpfile
success=$?
[ $success -eq 0 ] && mv $tmpfile $dumpfile
exit $success


Can you give that a try with the no_database patch and see if it works for 
you?

Jon


-- 
Jon Jensen
End Point Corporation
http://www.endpoint.com/