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

[Ron Phipps]

Jon Jensen wrote:
> 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.

It is a fairly early camp system, unfortunately I've used the same model 
for setup on all of the other mysql camps I have done as I was unaware 
of the "proper" way to do it.  I just always thought mysql camps had 
this extra step of creating the database before the dump was loaded.

> 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. :)

Sounds good to me.

> 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

What I have done in FCPU's case is used the normal nightly dump file for 
backup purposes, unzipped it and copied it to the proper location.  I 
like doing this so we do not have to hit the database server for another 
dump when they both run nightly.  I'll work on a bit of code to add the 
proper use and create statements.  Once I have that I'll test the 
no_database patch.

Thanks,


-- 
Ron Phipps
End Point Corporation
ron at endpoint.com
661-513-0640