I have installed Flyway in my server and trying to execute a My-sql file which I placed in sql folder of flyway.
I have done Flyway baseline, and when I run flyway migrate it says "Schema xyz is up to date. No migration necessary." No matter what I do it always gives me the same result.
My sql files are named 1__act.sql, 2__act.sql, 3__act.sql.
My config file has
flyway.url=jdbc:mysql://mysql:port/xyz
flyway.user=flywayuser
flyway.password=flywaypassword
flyway.baselineVersion=1
You haven't followed the naming conventions for Versioned SQL migrations, they should be prefixed with a V. e.g. V1__act.sql.
Note that the prefix is configurable, but above is the default.
/src/main/resources/db/migration needs to be a source folder in Eclipse/Spring Tool Suite. Right-click it, Build Path, Use as Source Folder.
Related
Is there a way where the database references in a SQL Server Database project (Dacpac) can be derived at run time?
We're building a product which uses Dacpac to deploy database objects.
Our product implementation teams also use Dacpac projects by adding database reference to the product Dacpac file and then adding their own additional objects to the project.
The problem we're facing is - every time the implementation needs to point to a newer product release version, the parent dacpac references in the implementation dacpac have to be changed manually to refer to the new file path of the new product dacpac (in the newer release). We've mutiple implementation teams and multiple database projects in each implementation.
Is there any way the database references (*.dacpac) in a database project can be derived at run time using a variable or parameter or something of that sort?
My understanding of your question is as follows:
You have a SSDT database project (see example image below), that has a database reference (similar to #1 below) with stored procedures and other db objects that access the reference database (similar to file #2 and code #3). You've 'built' the solution resulting in a DACPac and now you want to take this DACPac and reference other databases at deploy-time. Hopefully I understood your question correctly.
If so, then you can use the Publish Profiles feature to achieve this (similar to #4 below).
The code for this can be seen in my notes from my SSDT talk github project.
If you look specifically at the demo04 solution file, you will see that I have a DEV_MJE.deploy.ps1 PowerShell file and a DEV_MJE2.deploy.ps1 file. These scripts run MSBuild to build the DACPac and then use SqlPackage to publish DEV_MJE.publish.xml or DEV_MJE2.publish.xml respectively. Note, if you run this example on your machine, you'll need to add MSBuild.exe and SqlPackage.exe to your path, as well as modifying the TargetConnectionString in the xml files to an existing development database.
As an example of how this works...When I use the Publish Profile DEV_MJE.publish.xml, the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE].[dbo].[AnotherTable]
Whereas when I use DEV_MJE2.publish.xml the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE2].[dbo].[AnotherTable]
Notice the database reference in the second has changed to AnotherDb_MJE2.
For a good description of how Publish Profiles relate to DACPacs and SSDT Database Projects, see this web page. It also contains information on alternative ways to deploy beyond SqlPackage.exe.
Something else to consider
Note, that using file paths to version control a DACPac is not really the best practice. Consider the DACPac artifact as similar to a .Net DLL. It is the biproduct of a build.
As such, a better approach is to use NuGet and tools like Octopus Deploy to store, track, and deploy DACPacs. See the stackoverflow answer for a good description of how this works.
Hope that this helps,
Michael
Thanks for the followup comment, I think what you are trying to do is when you write and deploy your code be able to use different dacpacs depending on the project?
Each implementation team might have a different version of the shared dacpac deployed so you can't just put the files in a shared location and call the dacpac "Product_Latest.dacpac" or something, so everyone always gets the latest version.
".sqlproj" files are standard msbuild scripts and references can be managed using msbuild properties so you can technically change the reference at runtime. If you edit your .sqlproj file and add a property in the first <PropertyGroup> tag, I used:
<ProdDacpacVersion Condition="'$(ProdDacpacVersion)' == ''">v1</ProdDacpacVersion>
v1 is the unique name for the version folder - you just need something to identify the dacpac you want.
I put the property just after TargetDatabaseSet and IncludeCompositeObjects.
If you then find the reference to the dacpac and instead of
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\v1\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\v1\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Use the property from above:
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Then the reference will use the property to get the path of the dacpac. There are a few ways you can set the property, you could edit the .sqlproj file when you want to take a new version of read the property from a file or environment variable or something (i'll leave the msbuild fun to you!).
I would, as a standard, everytime the reference was changed either reload the project or restart visual studio - it won't take long and it will save lots of cursing :)
When you deploy the dacpac's, the deploy looks in the same folder for references first so just make sure you copy the right one into the bin folder when you deploy.
I am setting up a build in Visual Studio Team Services (formerly Visual Studio Online) for my NopCommerce application. The database connection string is defined in a file called Settings.txt and I would like the value to be updated by my build using a build variable.
I have tried using the $(varName) placeholder as suggested here , but it didn't do anything. Any suggestions? Thanks.
You can't use the variable placeholder directly in the file and there's currently no task available OOTB which does replace values inside of files. You'll need to pass it to a Script (PowerShell, Batch, etc) which replaces the value in the file.
You can use the tokenizer task to achieve this. I don't think that it is available in VSTS by default but you can upload it. You can find the instructions to upload and use in Readme.MD
More details at these two links
http://blogs.ripple-rock.com/rorystreet/2015/11/25/UsingVSTSReleaseWithTokenisationToDeployWebsites.aspx
https://github.com/TotalALM/VSO-Tasks/tree/master/VSO%20Tasks/Tokenization
I'm using the flyway command line tool. I'd like to setup different configuration settings for different environments (development/testing/production), but there will be some common settings. Ideally there can be a common.properties config, along with individual environment-specific configs (e.g. production.properties)
Does flyway support including properties from multiple config files in some way?
Yes, you can by exploiting the loading order of Flyway config files (http://flywaydb.org/documentation/commandline/#configFile)
Place the common settings in either
Flyway Install Dir/conf/flyway.conf
User Home Dir/flyway.conf
Current Dir/flyway.conf
You can then put the environment-specific properties in the file you specify with
-configFile=/path/to/envspecific.conf
We have a database project with views which join to tables in another database. The other database is in a different solution. This failed to build until we added a reference to a DacPac from the other database. I believe these views are considered “Composite Database Objects” because they reference objects not included as scripts in the database but rather referenced in the DacPac. We can successfully deploy this project from the VS to the target database.
Now we are trying to automate the deployment via MSDeploy. We have successfully deployed non-Composite database projects using DacPacs in the past by creating a package from a manifest. For example:
But in this case the deployment fails with the following error:
Error SQL0: The reference to external elements from the source named
'Other.dacpac' could not be resolved, because no such source is
loaded. Warning SQL72025: No file was supplied for reference
Other.dacpac; deployment might fail. When package was created, the
original referenced file was located D:\BUILDS\6\CORE SERVICES\ACME DB
(DEV2-DEPLOY)\SOURCES\ACME.SQLDEPLOY\DACPACS\Other.DACPAC.
Error: An error occurred while adding references. Deployment cannot
continue. Error count: 1.
Is there a trick to make sure the referenced DacPac makes it into the package and the deployment completes successfully?
In the end we had to:
Unzip the DacPac
Change the path of the referenced DacPac to be relative
Recalculate the checksum and update it
Rezip the DacPac
Not ideal, but in the end we now have an automated deployment process for DacPac referencing DacPacs.
This is an old question, but we've found that if the DACPAC cannot be found on the path referenced, you can include it in the same directory as the referencing DACPAC.
e.g., if ABC.dacpac references the msdb database, the referencing location is expected to be at C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\Extensions\SqlServer\120\SqlSchemas\msdb.dacpac
However, you can copy msdb.dacpac to the same directory as ABC.dacpac and Microsoft.SqlServer.Dac.DacServices will find it
I am working on a ASP.NET Web Forms project which is expected to experience lots of database changes even after deployment.
Our preference was to use Entity Framework 5, and the Database First design paradigm. However, since we have to make lots of changes to the database even after deployment, if I use database first approach, then every time I update my database, I will have to delete my entire model and regenerate it. Is there any best practices to make this process less painful?
You should use Code First, so that you can use Migrations.
More specifically I'd use manual Migrations.
With manual Migrations you can create Migrations at any point in time. A migration has the following information:
a snapshot of the current model
a set of "instructions" to upgrade from the previous migration
a set of "instructions" to downgrade to the previous migration
Apart from the necessary Migrations, you should add a new Migration when you deploy your app. For example, you can create a migration called "Version 1.0", when you deploy the version 1.0 of your app.
When you finish each new stable version, you simply add a new migration, for it, like "Version 1.1" or "Version 1.2".
The interesting part of migrations shows up when you have a deployed application version and you need to upgrade (or downgrade) to a new version.
There are commands that let you upgrade (or downgrade) a DB from one particular version
to another particular version. You can do it directly specifying a connection to the DB, or create a SQL script which will apply the changes to the DB. For example, if you deployed the version 1.0 in a customer server, and you need to upgrade the software to version 1.2, you can do this:
Update-Database -SourceMigration "Version 1.0" -TargetMigration "Version 1.2"
-Script
This will create a SQL script which can be run on the DB to upgrade from version 1.0 to 1.2.
If you need help about any of the Migrations commands, simply type:
get-help Update-Database -full
(Update-Database is a command name, you can specify any other like Add-Migration)
It's possible that you need to specify the project where the model is in, the connection string name, the name of the project with the .config file or some other things, depending on the specified parameters, and the structure of the projects in your solution.
To get more info on migrations, read MSDN EF Code First Migration.
NOTE ADDED IN EDITION: there is a new DB initializer that can automatically migrate to the latest version when the application runs. I've worked in a real application, and it works like a charm.
ALTERNATIVE SSDT
If you don't want to follow the advice, you can use SQL Server Data Tools (which can be installed inside VS, or work as an independente application, depending on the version you're using).
The idea of this tool is that you can compare projects (which are DB schema snapshots) to existing DBs, and generate the scripts to change the DB to match the schema in the project. (In fact you can compare any combination ofr project and DB)
If you keep versions of your project in a CVS you can even check the changes from one verison of the project to other version of the project.
NOTE ADDED IN EDITION: a SSDT project is a set of scripts that can build the whole DB, including all the objects in its schema. You can create it from an existing DB or viceversa. Then you can keep comparing any combination of DBs and SSDT projects, as soruce or target, and create an apply the scripts neccesary to change each particular object which has changes. (The scripts are created to change the target so that it looks like the source, but you can swap source and target easyly)
This is an alternative solution, but Migrations are much more powerful because you can customize them, for example to fill a "master table" when creating it, to set the initial value of a new column, and so on. If you use SSTD you'll have to do all of that by hand, and carefully keep track of it. So I highly recommend using Migrations.