I have a problem with my connection to MySql database. I generated an app with ASP.NET Core with target version .NET Framework 4.6.1.
My connection string looks like this:
"ConnectionStrings": {
"Default": "server=localhost;port=xxxx;database=MmpDb;user=user;password=***;" },
I added MySql.Data.Entities references for Mmp.EntityFrameworkCore and Mmp.Web.Host
I overwrite EF DbContext:
public class MmpDbConfiguration : DbConfiguration
{
public MmpDbConfiguration()
{
SetDefaultConnectionFactory(new MySql.Data.Entity.MySqlConnectionFactory());
SetProviderServices("MySql.Data.MySqlClient",
new MySqlProviderServices());
}
}
When I run the command dotnet ef database update I get an error that Keyword not supported: 'port'.
Can somebody provide a solution for this issue please?
Thanks
Since Entity Framework Core is new, there is not much mature drivers.
I suggest you to use Pomelo.EntityFrameworkCore.MySql for MySql connection.
Then, delete all migration files becasue they are generated agains MsSql.
Then regenerate migration files using Add-Migration command and it should work.
You can also check related issue on ABP's github repository here https://github.com/aspnetboilerplate/aspnetboilerplate/issues/2267.
Try to install these packages to your solution
Mysql.Data
Mysql.Data.EntityFrameworkCore
and then try to connect to mysql
Related
Upgrading springboot 2.0.3 to 2.1.1 also brings a new flyway version: 5.2.3 instead of 5.0.7.
In 5.2.3 SpringJdbcMigration is deprecated and will be removed in flyway 6. I use sql scripts mostly, but I also have one java migration class in a project (there are 4 sql migrations and the last one, 4.2, is a java migration - it was just some quick and dirty hack to change old data and I don't need it anymore).
So I changed that class:
class V4_2__Update_foo implements SpringJdbcMigration {
public void migrate(JdbcTemplate jdbcTemplate) throws Exception {
...
}
}
to
class V4_2__Update_foo extends BaseJavaMigration {
public void migrate(Context context) throws Exception {
JdbcTemplate jdbcTemplate =
new JdbcTemplate(new SingleConnectionDataSource(context.getConnection(), true));
......
}
}
This is the only change, everything else is the same. The result is
Application run failed
org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]:
Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException:
Validate failed: Migration type mismatch for migration version 4.2
....
Caused by: org.flywaydb.core.api.FlywayException:
Validate failed: Migration type mismatch for migration version 4.2
-> Applied to database : SPRING_JDBC
-> Resolved locally : JDBC
at org.flywaydb.core.Flyway.doValidate(Flyway.java:1479)
I don't want to disable validation permanently, but I also don't know how to solve this. I tried googling but found nothing concerning "type mismatch".
On my developer machine I tried "flyway repair", but it only said
Repair of failed migration in Schema History table "PUBLIC"."schema_version" not necessary. No failed migration detected.
Successfully repaired schema history table "PUBLIC"."schema_version"
The type of migration 4.2 is still "SPRING_JDBC" after running repair.
Later I deleted the java class completely which got me a warning that
Schema "PUBLIC" has a version (4.2) that is newer than the latest available migration (4) !
but at least the application was running again. I'm not really comfortable doing that in production, though. Any other ideas?
That's definitely a bug. Unfortunately this won't be fixed in 5.2.x. Flyway 6.0 (due in Q1 2019) will automatically correct your schema history table and fix this.
Alternatively if you really don't want to wait, you can manually path up the schema history table to make this message go away.
Problem:
[schema_version table with SPRING_JDBC][1]
[1]: https://i.stack.imgur.com/GI9So.png
SOLUTION:
I solve this issue by manually updating schema_version table using below query: update schema_version set type='SQL', checksum=662979041 where script='V001_026__initial_reconciliation_config_env_NonProd.sql';
However, to create above UPDATE statement, you will need checksum of actual script that you migrated previously using spring/java class which will not have checksum in it.
How to get that checksum?
In your local, delete the schema_version table in local. Start your app successfully, you should now have new schema_version table created with correct checksum and type as SQL.
checksum is to check the integrity of file, that means do no modify the file once you get checksum.
Then execute above UPDATE statement manually in your non-prod environment.
Next step, remove java class, move that script in folder like db/non-prod and configure that folder in application.yaml like
spring:
flyway:
locations: "classpath:db/migration,classpath:db/env/migration/V001/NON-PROD"
Migration data first time success.
But when I update entity and migration again, it fails:
Unable to generate an explicit migration because the following
explicit migrations are pending: [201712281248174_ttt]. Apply the
pending explicit migrations before attempting to generate a new
explicit migration.
Help! Thank you!
You have to enable automatic migrations in your migration configuration file.
public Configuration()
{
AutomaticMigrationsEnabled = true;
}
or explicitly run command Update-Database in Package Manager Console.
I'm trying connect my jhipster app with a custom mssql database. Right now it is connected to a fresh default MySQL db tied up with liquibase and has the default entites that come out-of-the-box with jhipster. I want to do 2 things :
Prevent any db modification scripts that liquibase may run on start up e.g. entity creation
Saftely move over to a different db with old applicaiton data and many custom tables than the one that is fresh and configured by default in jhipster .
To do '1' I tried to do the following in
public class DatabaseConfiguration {
liquibase.setDropFirst(liquibaseProperties.isDropFirst());
if (env.acceptsProfiles(Constants.SPRING_PROFILE_NO_LIQUIBASE)) {
liquibase.setShouldRun(false);
} else {
liquibaseProperties.setEnabled(false); // <<<<<< I DISABLED IT HERE
liquibase.setShouldRun(liquibaseProperties.isEnabled());
log.debug("Configuring Liquibase");
}
}
But still I can see that liquibase scripts are being run in start-up. Please advice if I'm doing this correct.
For #1, you could do it several ways, as you have both mssql and MySQL: you could either use the JDBC URL in DatabaseConfiguration or modify the Liquibase changelogs to add conditions on dbms to exclude them for mssql
For #2, you should look for existing tools to convert from one database engine to another.
we are using webApi for one of our newest products which is hosted on IIS7.5 and written in ASP.NET5 (.Net Core).
In earlier web-applications it was possible to change the connectionstring in the web.config in windows-Explorer and the website running on IIS used the ConnectionString in the web.config file.
Is this still possible for modern WebAPIs (I have the ConnectionString insite appsettings.json)? I did not find a solution for that inside IIS or File-Explorer and using Environment-Variables do not fit our needs.
We need to switch between several DB-Instances so a very light file-based solution would be very welcome.
PS: We are using EntityFrameworkCore (aka EF7) Database-First as it is a new tool that is on top of our current database.
You can use one of configuration sources (including JSON, accessed by AddJsonFile() in the package Microsoft.Extensions.Configuration.Json) to read the settings file and then use values read from there to configure EF.
Example code could look like this:
public Startup(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
.AddJsonFile("appsettings.json");
Configuration = builder.Build();
}
public IConfigurationRoot Configuration { get; }
public void ConfigureServices(IServiceCollection services)
{
services.AddDbContext<MyDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
}
For more information see Configuration in ASP.NET Core docs or this answer.
Is it possible to create a code-first Entity Framework model that connects to an existing database using ODP.Net without having any settings in the app.config file?
I have tried many different things.
Currently I am setting DbConfiguration:
sealed class EntityFrameworkConfiguration : DbConfiguration
{
public static readonly DbConfiguration Instance = new EntityFrameworkConfiguration();
EntityFrameworkConfiguration()
{
this.SetDefaultConnectionFactory(new OracleConnectionFactory());
this.SetProviderServices("Oracle.ManagedDataAccess.Client", EFOracleProviderServices.Instance);
}
}
DbConfiguration.SetConfiguration(EntityFrameworkConfiguration.Instance);
I am passing an OracleConnection directly into the EF context.
However, I either have problems with the SQL being generated in SQL Server format (using double-quotes around table aliases), or I get the following error:
An unhandled exception of type 'System.NotSupportedException' occurred in EntityFramework.dll
Additional information: Unable to determine the provider name for provider factory of type 'Oracle.ManagedDataAccess.Client.OracleClientFactory'. Make sure that the ADO.NET provider is installed or registered in the application config.
Has anyone any experience of getting this to work without polluting app.config with crud?
Yes. To complete the switch from machine.config/app.config to code-based configuration, I had to also include a call to SetProviderFactory().
public sealed class EntityFrameworkConfiguration : DbConfiguration
{
public static readonly DbConfiguration Instance = new EntityFrameworkConfiguration();
public EntityFrameworkConfiguration()
{
SetDefaultConnectionFactory(new OracleConnectionFactory());
SetProviderServices("Oracle.ManagedDataAccess.Client", EFOracleProviderServices.Instance);
SetProviderFactory("Oracle.ManagedDataAccess.Client", new OracleClientFactory());
}
}
I also called DbConfiguration.SetConfiguration(EntityFrameworkConfiguration.Instance); in the startup of my application because I had DbContext's in multiple assemblies that all needed to share this configuration.
On a side note, I have also found this to be effective in allowing your application to work around the ConfigurationErrorsException: The 'DbProviderFactories' section can only appear once per config file for cases where you may not have access to repair the user's machine.config.
Uff. Found the problem.
Because I was registering column mapping using lower case the query didn't work. The column and table names must be in upper-case.
How silly.