我刚升级到2.1.1版,现在我看到了一个奇怪的错误——当我在我们的登台和生产数据库服务器上的数据库上运行migrate命令时,migrate失败,出现了Flyway异常,但它在我们的开发服务器上运行得很好。
这是失败时的调试输出:
DEBUG: Adding location to classpath: C:\workspace\flyway\bin\..\jars\jtds-1.2.7.jar
DEBUG: Database: Microsoft SQL Server 10.0
DEBUG: DDL Transactions Supported: true
DEBUG: Schema: dbo
DEBUG: Schema [dbo] already exists. Skipping schema creation.
DEBUG: No upgrade to the Flyway 2.0 format necessary for metadata table [dbo].[schema_version]
DEBUG: No metadata table upgrade to the Flyway 2.0.2 format necessary
DEBUG: No metadata table upgrade to the Flyway 2.1 format necessary
ERROR: Unexpected error
com.googlecode.flyway.core.api.FlywayException: Current schema not set for connection! Check your database configuration!
at com.googlecode.flyway.core.dbsupport.DbSupport.getCurrentSchema(DbSupport.java:79)
at com.googlecode.flyway.core.Flyway$1.execute(Flyway.java:855)
at com.googlecode.flyway.core.Flyway$1.execute(Flyway.java:815)
at com.googlecode.flyway.core.Flyway.execute(Flyway.java:1177)
at com.googlecode.flyway.core.Flyway.migrate(Flyway.java:815)
at com.googlecode.flyway.commandline.Main.executeOperation(Main.java:118)
at com.googlecode.flyway.commandline.Main.main(Main.java:86)
很明显,它在检查元数据表时找到了模式,但由于某种原因,它不相信它是后来设置的。
模式本身在flyway.properties文件中定义
flyway.schemas=dbo
我找不到会导致此错误的dev和staging/prod之间的任何差异。
如果它有所作为,这是在“清洁”和“初始化”之后发生的......
对去哪里看有什么建议吗?
EDIT(对于将来遇到相同问题的人):Axel关于登录名在出现问题的服务器上没有默认架构是正确的。当我跑步时
SELECT SCHEMA_NAME()
在我们的DEV服务器上,我得到了“dbo”;但当我在我们的ACC和PROD服务器上运行时,我只会返回“NULL”。
嗯,似乎受影响系统上用户的默认模式为空。
请提交问题,我将在下一个版本中取消此检查。
同时,如果您为用户提供了一个默认模式,您应该可以。
我为命令行java迁移执行了以下步骤: < li >创建java文件 当我执行迁移逗号时,它会像 警告:无法解析位置类路径:db/迁移 请查看下面的附件图片,它实际上是罐子。我已经提取了更多信息。
我们使用Liquibase,现在在新项目中,我们必须使用Flyway。在liquibase中,迁移顺序在xml文件中,所以您可以指定什么是第一次迁移,什么是第二次迁移,它不依赖于名称。 所以,当一些开发人员添加新的迁移时,如果之前有人推动了新的迁移,那么他将在Git中遇到冲突,并且必须修复顺序。 这是如何在Flyway中实现的?如果并行添加迁移,如何控制顺序?
场景: < li >具有一个架构的现有数据库,即< code>transport架构。 < li>2个迁移文件,其中版本1是初始/基本版本。版本2向< code>management模式中添加了一个表(但没有创建该模式,我希望FlyWay来创建)。 使用FlyWay API(在Java应用程序中) 迁移版本2失败,因为尚未创建模式。这在干净的数据库上按预期成功。 我在通过maven插件执行迁移时遇
请让我知道我们是否可以将存储过程从Microsoft SQL server迁移到Microsoft Azure Cosmos DB?使用DocumentDB迁移工具或任何其他工具
我们正在我们的java,基于渐变Spring的MVC应用程序中使用飞行方式。我已将我的SQL文件保存在src/主/资源/数据库/迁移文件夹中。 下面是我的flyway gradle配置文件。 当我运行gradle flywayBaseline时,我得到如下输出。 它找到我的sql文件,但随后它没有执行它。 当我运行flywayMigrate时,我得到以下输出 这里的问题是什么?
应该如何使用像Flyway这样的数据库迁移工具来管理像存储过程这样的过程数据库代码? 与DDL不同,我不希望看到存储在多个数据库迁移文件中的存储过程发生变化。如何在源代码控制下在单个文件中管理过程代码,同时利用Flyway这样的工具进行数据库迁移?