The symptom of the problem is 3 fold, with gradle:
- flywayMigrate fails with org.flywaydb.core.api.FlywayException: Validate failed: Detected applied migration not resolved locally: 1.1
- flywayInfo reports numerous migrations as Missing, basically all the JDBC migrations.
Versioned 1.0 create initial db SQL 2013-04-05 10:49:18 Success
Versioned 1.1 InsertEnum JDBC 2013-04-05 10:49:18 Missing
Versioned 1.2 InsertDefaultCampaign JDBC 2013-04-05 10:49:18 Missing
While actually at a DB level, the schema_version tables reports them as
2 2 1.0 create initial db SQL V1_0__create_initial_db.sql 1924949074 ACCTESTING 05-APR-13 10.49.18.288446000 AM 1843 1
3 3 1.1 InsertEnum JDBC cern.acctesting.db.migrations.base.V1_1__InsertEnum ACCTESTING 05-APR-13 10.49.18.486188000 AM 95 1
4 4 1.2 InsertDefaultCampaign JDBC cern.acctesting.db.migrations.base.V1_2__InsertDefaultCampaign ACCTESTING 05-APR-13 10.49.18.652105000 AM 83 1
logs from the task report that these classes are found:
13:43:01.219 [QUIET] [system.out] [DEBUG] - Found class: cern.acctesting.db.migrations.base.V1_1__InsertEnum
13:43:01.220 [QUIET] [system.out] [DEBUG] - Found class: cern.acctesting.db.migrations.base.V1_2__InsertDefaultCampaign
On the other hand, numerous other classes are skipped:
13:43:01.265 [QUIET] [system.out] [DEBUG] - Skipping non-instantiable class (invocation error): cern.acctesting.db.migrations.content.V2_3_2__CreateTestPhaseAndSignOnlyTestsForBeamLossMonitors
there is no fundamental difference in the class structure.
I've a database that executed multiple migrations up to 3.5.2 in the past. It was running on Oracle 11g with Flyway 3.1. I'm now upgrading everything to Oracle 18c and Flyway 5.2.4. I'm using gradle 4.9 and the plugin flyway-gradle-plugin:5.2.4
Note maybe related or not to the problem, I had to manually edit the schema_version table to change the Type INIT to BASELINE (as well as the corresponding checksum).
I tried to remove all deprecation adapting all my migration classes to the 5.2.4 BaseJavaMigration, without success.
I then tried to use the flyway command line 5.2.4, building a jar from my IDE where I ran Gradle and using it in the CLI. Then I got more confused:
Versioned 1.0 create initial db SQL 2013-04-05 10:49:18 Success
Versioned 1.1 InsertEnum JDBC 2013-04-05 10:49:18 Success
Versioned 1.2 InsertDefaultCampaign JDBC 2013-04-05 10:49:18 Missing
I tried to reproduce the issue locally, executing in a unit test similar code to what flyway does. I couldn't reproduce the issue.
I've been running gradle in debug mode and no-daemon to attach a debugger and see how the class was loaded. I didn't spot anything wrong... it relies on a URLClassLoader that contains the entire classpath and it seems correct.
There is no fundamental difference between migration 1.1 and 1.2
#Transactional(propagation=Propagation.REQUIRED)
public class V1_1__InsertEnum implements JdbcMigration {
#Override
public void migrate(Connection connection) throws Exception {
insertTestStepStates(connection);
insertSignatureTypes(connection);
insertLocktype(connection);
}
/// some private method definitions
}
#Transactional(propagation = Propagation.REQUIRED)
public class V1_2__InsertDefaultCampaign implements JdbcMigration {
#Override
public void migrate(Connection connection) throws Exception {
long campaignId = getCampaignId(connection);
insertDefaultCampaign(connection, campaignId);
insertDefaultTestPlan(connection, campaignId);
insertActiveCampaign(connection, campaignId);
}
/// some private method definitions
}
I had them ported to extend the BaseJavaMigration, or even to implement the JavaMigration myself. It changed nothing.
So here are my current observations and problems:
- for the same code, I've an inconsistent behavior between the flyway command line tool and the gradle flyway plugin, both version 5.2.4
- most of my classes are not loadable by Flyway and I've no idea why
- the loaded classes are anyway not resolved locally and I've no idea why
Maybe I'm missing something super obvious and digging too deep for nothing?
Any idea what's wrong?
Related
Environnement:
php 8.1
symfony 5.4
doctrine/dbal 3.3
doctrine/doctrine-bundle 2.7
doctrine/migrations 3.5.1
postgresql 14.4
My problem is the following;
We have a database containing several schema to separate the data useful to the system and those published directly to users.
We use of course the classic entity declaration with Symfony & Doctrine:
/**
* #ORM\Table(name="stats", schema="system")
* #ORM\Entity(repositoryClass="App\Repository\System\StatsRepository")
*/
class Stats
The problem is that when we delete a relation between the public schema and the system schema, the migration generated by the command bin/console doctrine:schema:update has an error when deleting the index.
Here is the migration generated:
public function up(Schema $schema): void
{
// this up() migration is auto-generated, please modify it to your needs
$this->addSql('DROP INDEX idx_2225600edc6d4b4b');
$this->addSql('ALTER TABLE system.stats DROP article_id');
}
The problem being that in deleting the index, the line forgets to specify that the index comes from the system schema.
We need:
$this->addSql('DROP INDEX system.idx_2225600edc6d4b4b');
We want to keep the bin/console doctrine:schema:update operation for updating the database, but this problem now forces us to use the migration system to change the drop index.
I know that the obvious solution would be to use the migration system (bin/console make:migration) but this implies some changes in the IC. That's why I'm wondering; have you ever had this problem? If yes, how did you solve the problem?
I am getting error on debug session start on my dot net core API project; since I updated visual studio to latest version 17.1.1. Following is the exception detail, it is showing on console. I tried by deleting temp, bin, obj folders but nothing worked. Has somebody faced such an issue or know how to fix?
Unhandled exception. System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'ConfigurationManager'.
at Microsoft.Extensions.Configuration.ReferenceCountedProviderManager.AddProvider(IConfigurationProvider provider)
at Microsoft.Extensions.Configuration.ConfigurationManager.AddSource(IConfigurationSource source)
at Microsoft.Extensions.Configuration.ConfigurationManager.Microsoft.Extensions.Configuration.IConfigurationBuilder.Add(IConfigurationSource source)
at Microsoft.AspNetCore.Builder.WebApplicationBuilder.<>c__DisplayClass25_0.b__2(HostBuilderContext context, IServiceCollection services)
at Microsoft.Extensions.Hosting.HostBuilder.CreateServiceProvider()
at Microsoft.Extensions.Hosting.HostBuilder.Build()
at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
at Program.$(String[] args) in Program.cs:line 40
It is because you use the old way of getting the settings from the configuration manager, like:
using (var serviceProvider = services.BuildServiceProvider())
{
...
}
If you remove these lines and just use the configuration as-is with
options = configuration.GetOptions<Object>("xxx");
it will work
we also had this issue since march 8.
is was introduced with the release of 6.0.3, see a github post about the issue : https://github.com/dotnet/aspnetcore/issues/40614
for now what we did is revert to the 6.0.2 version (this is a temporary work around, i will hope to figure out what was wrong asap)
for docker images:
FROM mcr.microsoft.com/dotnet/aspnet:6.0.2 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:6.0.200 AS build
WORKDIR /src
if you are using it in yml also probably
use dotnetversion
DotNetVersion: "6.0.200" instead of "6.0.x"
6.0.200 is the sdk version of 6.0.2 framework https://dotnet.microsoft.com/en-us/download/dotnet/6.0
11/03/2022
see also this https://github.com/dotnet/core/issues/7259 were i have pinpointed the issue in our code and added a sample app to reproduce
if we look into that repo https://github.com/microsoft/ApplicationInsights-Kubernetes/blob/69f44c6ec3fda26d76a01836b851402e3f8a02ad/src/ApplicationInsights.Kubernetes/Extensions/ApplicationInsightsExtensions.cs
we indeed find the same piece of code on the other answers
i faced to this problem when i update my SDK both in docker and my window 11
my sdk is : 6.0.3
but i cant understand why this problem is happend
I have a clean marklogic server installation together with gradle DHF(Data Hub Framework) 3.0 project.
In the build.gradle, I have a custom task that triggers an input flow and loads the files by using MLCP.
The code looks like the following.
task importEntity(type: com.marklogic.gradle.task.MlcpTask) {
classpath = configurations.mlcp
command = "IMPORT"
...
...
transform_module = "/com.marklogic.hub/mlcp-flow-transform.xqy"
transform_namespace = "http://marklogic.com/data-hub/mlcp-flow-transform"
... }
When the command is run, the execution fails due to a non-existing module (/com.marklogic.hub/mlcp-flow-transform.xqy) in MarkLogic modules database.
If I check modules database, I see that the only custom modules were uploaded but not a single dependency from MarkLogic on mlDeploy.
I am wondering, what could have gone wrong.
Thank in advance.
Best,
Igor
The following code:
Database.SetInitializer
(new MigrateDatabaseToLatestVersion<Db, Migrations.Configuration>(true));
using (var C = new Db())
{
Console.WriteLine(C.Usuarios.Count());
}
Works on a console test project but on the other console with self-hosting it fails with the Unable to update database to match the current model... migration error
Obviously the migrations are up to date since the other project runs fine and they both do the same configuration since the database model and the migration configuration are on a separated library
I tracked down the problem to the Newtonsoft.Json library.
The package Microsoft.AspNet.WebApi.Client depends on the version 6.0.4 of this library which seems to have conflicts with Entity Framework.
Just upgrading the Newtonsoft.Json with Install-Package Newtonsoft.Json solves the problem
We use a .cfg file in ./etc directory to configure our bundle in ServiceMix. Everything worked fine in SMX 4.5.3, but when migrating to the 5th version the file is not picked up. When the bundle encounters a property the following exception is thrown:
java.lang.IllegalArgumentException: Property with key [xslt.dir] not found in properties from text: {{xslt.dir}}, StackTrace: org.apache.camel.RuntimeCamelException: java.lang.IllegalArgumentException: Property with key [xslt.dir] not found in properties from text: {{xslt.dir}}
However, if I put the properties in default-properties section in my blueprint configuration, it works.
Also, the console command config:list actually shows the properties for the bundle in spite of the exception:
Pid: misrouter
BundleLocation: mvn:ru.mig/mis-router/1.0-SNAPSHOT
Properties:
service.pid = misrouter
felix.fileinstall.filename = file:/home/petr/programs/5.0.0-apache-servicemix/etc/misrouter.cfg
xslt.dir = /home/petr/programs/5.0.0-apache-servicemix/xslt
So was something changed in SMX 5 configuration mechanism or is there a bug in it?
What version of the JDK/JRE are you using? When I was trying this out a few minutes ago to answer your question, I also had some problems using the 1.7.0_15 version I had installed and upgrading to the latest 1.7.0_51 fixed those for me.
Actually it's related to Camel vm component, a bug was created for SMX