If you have a look at the MySQL ddl script https://opencast.jira.com/svn/MH/trunk/docs/scripts/ddl/mysql5.sql you will notice that the first lines are:
drop schema if exists matterhorn;
create schema matterhorn DEFAULT CHARACTER SET = 'utf8';
This will probably work in most cases. But it might also delete an old database you want to keep (i.e. “matterhorn” is the name of the 1.3 database, you want to keep it and created a new db for 1.4 called “matterhorn14”)
Furthermore, all documentation regarding Matterhorn and MySQL tell you to create a new database anyway. So just remove these tree lines and tell the user to execute the SQL code in the db of his choice.
This script is meant to be used in new installations, which by definition should not have those tables. I'm not sure that we should be renaming things on our own either, I would rather leave it up to the relevant ops people to manage their own databases. I'm not seeing the issue here.
> I would rather leave it up to the relevant ops people to manage their own database
That is exactly the point. The user should manage the database. The current script, however, will delete a database as it's first action. If it was already existent and contained data …they are gone.
Of cause a user can look into the script, notice it and delete the line, but most users will just run the script.
Furthermore, these lines should not even be necessary. All our guides for connecting MH to MySQL state as first steps, that you should create a new MySQL database. Have a look at:
https://opencast.jira.com/wiki/display/MHTRUNK/MySQL+Database+Configuration # ok, this new one I wrote yesterday
So in the best case the user will create a new database names “matterhorn”, it will be deleted by the script and created by the script again. So the user has done unnecessary things, but apart from that, no harm is done.
But if the user chooses to name the database other than “matterhorn”, the script will not work.
And if there was already an existent database called “matterhorn” it will be deleted and the script will cause data lasses.
So in the best case nothing is gained by these lines but in the worst case it will delete valuable data.
Resolved in trunk with rev 15220, merged to 1.4.x with rev 15221.