I am wondering if there is any news for multi line comment directive support for MySql.
I believe the problem is related to:
Mysql dump comments directives and simple comments
Basically it seems SqlScript/MySQLSqlStatementBuilder fail in recognizing as directive a statement in the format:
/*!50001 <STATEMENT SPLITTED IN
MULTI
LINES> */;
I am using version 2.2.1
Additional notes:
the same goes for previous versions (2.1.1), and issues are multiple and not only related to comment directives; theu are also hard to debug because of missing exception trace.
Basically I think parser cannot currently handle pretty standard mysql scripts created with mysqldump; this IMO is a necessary feature for any usage in existing projects at least.
If anybody has suggestions to overcome these issues, it would be highly appreciated.
I am using Flyway 2.1.1 API in Java.
What I am doing is parsing a dump file (only the schema structure) and replace the version dependant comments.
This solution is pretty bad, but waiting for a better support of MySQL dump in Flyway, I didn't find anything else...
Related
I'm trying to upgrade a unit test project to the latest version of FakeXrmEasy 2.1.2 and I'm getting the error below:
'XrmFakedContext' does not cointain a definition for 'ExecutePluginWith' and no accessible extension method 'ExecutePluginWith' accepting a first argument of type 'XrmFakedContext' could be found
Any ideas what I'm missing?
This might happen because some methods were moved into dedicated namespaces and so some extra using statements might be necessary.
Please try adding these usings:
using FakeXrmEasy.Abstractions.Plugins;
using FakeXrmEasy.Plugins;
Also please check the documentation site with other steps that might be useful. In particular the Quick Guide to migrate in 6 steps is probably an essential resource:
https://dynamicsvalue.github.io/fake-xrm-easy-docs/quickstart/migrating-from-1x/
Basically, I'm curious if something like SBT including the version number in a program is possible for Scala.js. The proposed solution doesn't work in scala.js, apparently due the the absence of the getPackage method:
[error] Referring to non-existent method java.lang.Class.getPackage()java.lang.Package
Use sbt-buildinfo for that. The Usage section of the readme contains everything you need.
I need to be able to perform all of the available functions that the Package Manager Console performs for code first DB migrations. Does anyone know how I could accomplish these commands strictly through user defined code? I am trying to automate this whole migration process and my team has hit the dreaded issue of getting the migrations out of sync due to the number of developers on this project. I want to write a project that the developer can interact with that will create and if need be rescaffold their migrations for them automatically.
PM is invoking through PowerShell and PS cmdlets (like for active directory etc.)
http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference
The Package Manager Console is a PowerShell console within Visual
Studio
...there is essentially very little info about this - I've tried that before on couple occasions and it gets down to doing some 'dirty work' if you really need it (not really sure, it might not be that difficult - providing you have some PS experience)
Here are similar questions / answers - working out the PS comdlets is pretty involving - in this case it has some additional steps involved. And PS tends to get very version dependent - so you need to check this for the specific EF/CF you're using.
Run entityframework cmdlets from my code
Possible to add migration using EF DbMigrator
And you may want to look at the source code for EF that does Add-Migration
(correction: this is the link to official repository - thanks to #Brice for that)
http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs
http://entityframework.codeplex.com/SourceControl/BrowseLatest
(PM errors also suggest the origins of the code doing the Add-Migrations to be the 'System.Data.Entity.Migrations.Design.ToolingFacade')
If you need 'just' an Update - you could try using the DbMigrator.Update (this guy gave it a try http://joshmouch.wordpress.com/2012/04/22/entity-framework-code-first-migrations-executing-migrations-using-code-not-powershell-commands/) - but I'm not sure how relevant is that to you, I doubt it.
The scaffolding is the real problem (Add-Migration) which to my knowledge isn't accessible from C# directly via EF/CF framework.
Note: - based on the code in (http://entityframework.codeplex.com/SourceControl/changeset/view/f986cb32d0a3#src/EntityFramework.PowerShell/Migrations/AddMigrationCommand.cs) - and as the EF guru mentioned himself - that part of the code is calling into the System.Data.Entity.Migrations.Design library - which does most of the stuff. If it's possible to reference that one and actually repeat what AddMigrationCommand is doing - then there might not be a need for PowerShell at all. But I'm suspecting it's not that straight-forward, with possible 'internal' calls invisible to outside callers etc.
At least as of this post, you can directly access the System.Data.Entity.Migrations.Design.MigrationScaffolder class and directly call the Scaffold() methods on it, which will return you an object that contains the contents of the "regular" .cs file, the "Designer.cs" file and the .resx file.
What you do with those files is up to you!
Personally, I'm attempting to turn this into a tool that will be able to create EF6 migrations on a new ASPNET5/DNX project, which is not supported by the powershell commands.
I use maven for db migration with flyway. And I want to use names of sql scripts like: "test_1.1.sql". But flyway throws exception: "com.googlecode.flyway.core.api.FlywayException: Wrong migration name format". If I use name: "test_1.1__some_description.sql", all goes fine.
But such format isn't acceptable for me. How to solve this problem?
This is not currently possible. It used to be an option in pre-2.0 versions. Removing it made it possible to detect a bunch of possible mistakes, which couldn't be reliably identified before.
On a all but the most trivial projects, having a description makes a lot of sense.
If you feel we overlooked a valid real world usecase for not having a description, please file an enhancement request in the issue tracker.
There are some properties for modify flyway migration scripts naming convention.
Properties Name: sqlMigrationPrefix and sqlMigrationPrefix
In your Case test is prefix for migration script and suffix is .sql.
So, Your properties should be set like:
flyway.sqlMigrationPrefix = test
flyway.sqlMigrationPrefix = .sql
At Last, Your naming convention should be "test1_1__Some_Description" where
__ is use for separator for "Migration Script Description".
What method do you use to get a compile time error when the database schema changes occur in an ASP.NET project?
For example, if you have a GridView bound to a DataSource, I can only get runtime errors when a schema change occurs, not a compile time error. Intellisense works fine on the code behind using datasets, LINQ, etc, but I cant seem to get a compile time error on an ASP.NET page when I change the schema.
Any advice?
Create a unit test that verifies the correctness of you data access layer, and make sure it covers all your DB-related code. Not everything can be caught at compile time...
One way I can think of easily achieving this behavior would be to databind to a dynamic DAL. There are some tools that can help do this DAL generation, I'd recommend taking a look at SubSonic.
Once you have something like SubSonic in place you can bind to the resulting business objects. These business objects will automatically change in the case of a schema change in the database and this will break your binding code which will result in a compile time error.
Update
Assaf's recommendation to use Unit Tests is also a good idea. It doesn't solve your stated problem but it is definitely something that should be in place and is a great tool for flagging these type of problems.
We use a modest system (xml to c++) to create schemas from an independent description, this system also creates names for tables and columns that we use inside the code, when there is a change in the schema the names change, as the names we originally used are not there anymore and the compiler will flag an error.
You could probably configure a lot of the DAO generation tools to do something similar.
One solution would be to version your database and map an application build to a specific version (maybe in a properties file). In the entry point of your app, you can compare the expected version to the actual version and handle the error accordingly.
I'm not sure whats the equivalent in ASP.net of Migrations in Rails or dbdeploy in Java for versioning your database. But any DB versioning tool that makes schema changes incremental and versioned and tracks the version in a Version table will suit the purpose.
But if you want a compile time error while building your app, you might as well upgrade your schema to the latest version as part of your build process, avoiding the possibility of schema changes in the first place.