sougatamondal / migratordotnet

Automatically exported from code.google.com/p/migratordotnet
0 stars 0 forks source link

Add ability to create database if it does not yet exist #37

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I want to totally automate the creation of my database using migrator.net.
 However currently you are required to first create the database manually
before running any migrations.  Is it possible to add a setting that would
automatically create the database if it does not yet exist?  

Thanks
Carel

Original issue reported on code.google.com by carel.l...@gmail.com on 17 Jun 2008 at 9:11

GoogleCodeExporter commented 8 years ago
Hi, for a development environment you should be working with some automatic 
building 
tool like nant and msbuild and using both of them you can create a DB and drop 
it at 
the end (if needed)
For a production environment it is very problematic to do a simple CREATE 
DATABASE...which collation do you want? is CI-AS or CS-AI...which size for the 
logs 
files in which disks? opening a DB for production is a big issue with a lot of 
decisions.
So, in production you won't need this, in tests you are doing it in your 
nant/msbuild.

Original comment by gustavo.ringel@gmail.com on 17 Jun 2008 at 9:49

GoogleCodeExporter commented 8 years ago
Point taken - I am not interested in doing this for production at all.  
Currently we
are creating our DB'es by running different script files that are automated via
MSBuild.  I'm looking to replace the process for the development environment 
using
Migrations.  The only part of the scripting process that Migrations do not 
cover is
the creation of the DB.  It seems like I'll be using a combination of script 
files
and Migrations then to accomplish it.

Original comment by carel.l...@gmail.com on 18 Jun 2008 at 5:35

GoogleCodeExporter commented 8 years ago
Does Database.ExecuteNonQuery("CREATE DATABASE Foo") work as a work around? Your
first migration could do that possibly. I'm not sure how that impacts the 
connection
string. But can you try that and let us know.

If not, we can look into this. Gustavo raises valid points, but if we can make 
the
simple cases simple and the hard cases possible - that would be a win. The 
simple
case to me is default everything (collation, log/file locations, etc).

Original comment by geoffl...@gmail.com on 19 Jun 2008 at 2:25

GoogleCodeExporter commented 8 years ago
Does Database.ExecuteNonQuery("CREATE DATABASE Foo") work as a work around? Your
first migration could do that possibly. I'm not sure how that impacts the 
connection
string. But can you try that and let us know.

If not, we can look into this. Gustavo raises valid points, but if we can make 
the
simple cases simple and the hard cases possible - that would be a win. The 
simple
case to me is default everything (collation, log/file locations, etc).

Original comment by geoffl...@gmail.com on 19 Jun 2008 at 2:27

GoogleCodeExporter commented 8 years ago
Hi Geoff i don't see my comment here, maybe i didn't send it, i suggested that 
as a 
workaround, but it cannot be migration 1 of the DB. If it works it should be 
migration 1 of another Migration that connects to master or some the 
corresponding 
system DB...We cannot execute Database.ExecuteNonQuery(...) in a migration 
connected 
to the DB we want to create.

Original comment by gustavo.ringel@gmail.com on 19 Jun 2008 at 4:06

GoogleCodeExporter commented 8 years ago
As Gustavo mentions it won't work as the Migration opens a connection to the DB 
that
you are executing the migration on.  As the DB doesn't yet exist, the migration 
won't
work either.

Original comment by carel.l...@gmail.com on 19 Jun 2008 at 6:24

GoogleCodeExporter commented 8 years ago
perhaps we could create another nant task that first attempts to create the db, 
then 
continues on with the migrations?

I have a generic <exec> task I am using right now that uses osql.exe to create 
the 
database before running the migrations.

I think it would be beneficial if we incorporate this step into migrator as it 
is a 
common task that is performed when using migrations. at least for me.

Original comment by dko...@gmail.com on 6 Aug 2008 at 12:26

GoogleCodeExporter commented 8 years ago
I was just thinking that InitializeOnce() might be used for this as well?

Original comment by geoffl...@gmail.com on 22 Dec 2008 at 5:31

GoogleCodeExporter commented 8 years ago
+1 for this. It would be nice to do all of this as part of the Migration 
instead of relying on a separate step from a different build. 
For example, for some of our integration tests and some of our load test we do 
this as part of the initialization. Now, the easiest way to do it would be 
directly using a SqlCommand, but then when we do a deployment MSBuild/Nant/PS 
might be a better option depending on how we're deploying so now we have this 
extra step that's different. Not a big deal since is really simple, but it just 
feells that it belongs to MigratorDotNet

Original comment by m...@miguelmadero.com on 1 Sep 2011 at 4:06

GoogleCodeExporter commented 8 years ago
Could you connect to "Master" and run the create Database script.  This would 
only work for "SQL" or whatever environment you scripted it for but it might be 
a solution.  Also the identity of Authentication would need the appropriate 
rights... might be a way to stop it from working on live. 

Original comment by Skyler.T...@gmail.com on 1 Jun 2012 at 5:44