Open GoogleCodeExporter opened 9 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
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
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
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
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
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
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
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
+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
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
Original issue reported on code.google.com by
carel.l...@gmail.com
on 17 Jun 2008 at 9:11