I'm trying to use flyway migrate oracle database, According to the official website said to operate,it seems migrate successful, but I can not found table in the database.
Database: jdbc:oracle:thin:#localhost:1521:orcl (Oracle 11.2).
Validated 4 migrations (execution time 00:00.176s).
Current version of schema "lffair": 1.
Migrating schema "lffair" to version 1.0.1.
Migrating schema "lffair" to version 1.0.2.
Successfully applied 2 migrations to schema "lffair" (execution time 00:00.181s).
sql>desc schema_version;
sql>Object schema_version does not exist.
sql>desc dept;
sql>Object dept does not exist.
Look in the lffair schema. That's where the table was created.
Related
I have a Hasura project with 3 environments: local, staging and prod
In order to develop locally with the latest data from PROD, I have written a script that dumps and restores PROD db locally
However, when trying to migrate the locally restored PROD db, I run into issues because the migration state is corrupted. Some migrations have been ran on PROD but they appear as not ran locally although it is exactly the same db.
When running hasura migrate status against PROD and local, I do see different results indeed
Howeve,r when inspecting the table hbd_catalog.schema_migrations on PROD and locally it contains exactly the same data...
What's even more confusing is that although PROD correctly marks some of my migrations as ran, their timestamp is not present in the migration table on PROD db...
Is there some other place that Hasura uses to keep track of these migrations?
What version of Hasura are you using? In Hasura 1.x the schema_migrations table was the location for tracking migrations but in in Hasura 2.x this got changed and they are now stored in the hdb_version table as a JSON blob in the cli_state column.
I had similar confusion after upgrading from 1.x to 2.x because the schema_migrations table is still left behind which made me thing it was still in use, but any records there are just vestigial and you can safely delete the table.
I am trying to use migrations with a existing database and to create a new one, if not exists.
The EF Core documentations says:
If you created the initial migration when the database already exists, the database creation code is generated but it doesn't have to run because the database already matches the data model. When you deploy the app to another environment where the database doesn't exist yet, this code will run to create your database
From EFCore docs
I did initial migrations, it creates a up and down methods to create my tables. When I run it to a new database (new database name in connection string) it creates the database and tables as expected.
But if I run it to an existing database (not created by migrations), it fails at the first up method that tries to create a table that already exists, and the migrations stops to run.
Docs says "it doesn't have to run", but first thing migrations is doing is try to create an existing table.
How to prevent migrations to try to create existing tables? There is something like "create if not exists" built in on migrations? Is documentations right? It should works as expected/describe in docs?
If I'm doing it wrong, what is the strategy to work with migrations to run with existing and new on databases?
Dotnet Core version: 1.1.
EFCore version: 1.1.2.
Thanks in advance.
You need a baseline migration for the existing database. In EF 6 you used the -IgnoreChanges flag, but that doesn't exist in Core right now. See here.
You can accomplish the same thing in EF Core by commenting out all the Up() code and applying that migration. This will create the __MigrationHistory table and insert a record denoting it has been applied.
Subsequent migrations will be applied to both and if you need to create a new database you are covered.
I tried to update my (Oracle) database to Flyway 4.0 from Flyway 3.x today. I can see the update script tries to remove a couple of indexes (_vr_idx and _ir_idx). The problem I'm facing is the update has failed mid-way and now every time I rerun it, it complaints about the indexes not existing...
How do I proceed?
This is a known issue fixed in the upcoming Flyway 4.0.1.
In your case you have 3 options:
Drop the schema_version table and baseline the schema with Flyway 4.0
Manually perform the remaining actions on the schema_version table, followed by repair with Flyway 4.0
Recreate the dropped indexes and try again with Flyway 4.0.1
I want to create a table on schema TESTE234. The metadata, schema_version table, is on Flyway schema. So I configured:
flyway.user=teste234
flyway.password=xxxx
flyway.url=jdbc:oracle:thin:#//xxxx:1521/xxxx
flyway.schemas=FLYWAY, TESTE234
But it´s appear the insufficient privilege message. What is the problem?
The first schema is default schema, so by running in this way, it will try to deploy on FLYWAY schema, on which you don't have rights to create anything.
SO options are:
give rights to teste234 on flyway objects
Put test234 before FLYWAY: flyway.schemas=TESTE234, FLYWAY
I am currently using Flyway version 1.7. I read in the release notes that Flyway 2.0 comes with a new metadata table format and all 2.x versions do an automatic upgrade on first run. All fine so far. But what if I have to rollback my application and downgrade Flyway back to 1.7? Will the old Flyway work with the new metadata format? Is there a rollback script to get the old metadata table format back?
I am using PostgreSQL as database engine.
No, it's a one-way upgrade. It does run within a transaction though, so in the very unlikely event it would fail, the transaction would be rolled back.