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
Related
Is it possible to use a different migration framework for your relational database with hasura?
I am seeing hasura has the ability to manage migrations as noted in the documentation here.
We are using liquibase as the migration framework for all of our other projects and want to use hasura, but keep our existing migration framework (liquibase).
In the setup documentation already linked above, there's a prompt that asks if you want to initialize the project with metadata and migrations. Is it as simple as saying no here?:
? Initialize project with metadata & migrations from https://docs-demo.hasura.app ? Yes
Can this be done or do you have to use the hasura migrations if you want to use hasura?
Yes, you can manage your database migrations however you want to, and you have no obligation to use Hasura. Hasura's migrations are just a collection of .sql files that can be applied/revoked sequentially.
What is critically important is that you keep Hasura's metadata in sync with the database state.
For example, if you're tracking a database column in Hasura, and you use a SQL client to drop that column in your DB, Hasura's metadata (which describes the tables, columns, etc. that are exposed through the API) will be inconsistent with the database state. The proper way to manage a task like that is to either (1) use the Hasura console UI, (2) use the Hasura metadata HTTP API, or (3) manually edit and apply metadata with the Hasura CLI.
The task of keeping Hasura metadata in sync with DB state becomes non-trivial very quickly as you start to make use of features like "actions" and "events". You should run through some real-life migration scenarios with your current set up to get a sense of the challenges.
I have existing database postgres which not using Flyway and i need replicate it.
How to move existing database state to new empty database?
I don't have any migration sql.
So I am expecting command like generateChangelog in Liquibase but it seems in Flyway not existing command like that.
Flyway currently only manages the scripts that you create. It doesn't create scripts for you. So, in order to take an existing database and get it into Flyway processing, you'll need to generate the scripts for that database. You can use the methods outlined here to get the scripts for your database. Then, just rename them to the Flyway standard. You'll be off and running.
I am running flyway migrations on a postgres DB with existing tables. In doing so flyway threw this error
Found non-empty schema(s) "public" but no schema history table. Use baseline() or set baselineOnMigrate to true to initialize the schema history table.
After reading the docs on baselineOnMigrate, all we need to do is toggle this to true and we should be able to complete the migrations.
Need clarity on enabling this feature:
do we set FLYWAY_BASELINE_ON_MIGRATE to TRUE only once and when the schema history table is created we can turn it back to FALSE? Or do we have to persist the TRUE value?
Yes, you'd set it only once. That approach is really only used where Flyway takes all its parameters from the configuration file...it is just intended for a single use (e.g. just for one specific copy of a database, out of many). Normally, you baseline from an action at the command line like this:
Flyway baseline #FlywayArgs -baselineVersion='1.3.1' -baselineDescription='Existing version of MyDatabase'
This article is using a SQL Server database rather than Postgres but might give a good idea of how flyway baselines work: https://www.red-gate.com/hub/product-learning/flyway/flyway-baselines-and-consolidations.
So just exploring the possibility of using flyway to maintain my DDL statements against Amazon Athena using Athena provided JDBC driver, Athena supports only CREATE statements (hive DDL) and no INSERTS.
So if database metadata table is the only one that flyway creates and updates, Is there anyway I can externalize the creating, storing into a totally different database ?
Currently this is not possible in flyway, as the schema history is read from/written to the database defined by the current jdbc connection. You can see this for yourself in the JDBCTableSchemaHistory file.
If you wish to add this support, you could create a pull request on the repo, or just add an issue detailing exactly what you want the behaviour to be.
I am trying to modify my code first migration so that I can add a new table to the db, called "GunControl." However, when I enter "Add-Migration GunControl" in the package manager, I get the error message:
"Unable to generate an explicit migration because the following explicit migrations are pending: [201705171404346_Questionnaire]. Apply the pending explicit migrations before attempting to generate a new explicit migration."
QuestionnaireDbEntities.mdf is the name of by db, and GunControl inherits from the class Questionnaire. I have looked everywhere online, and I can't find a way to do this. Thank you so much for your time!
This occurs because you have an existing database already that you're connecting to. The database keeps track of what migrations have been applied to it and when you run Add-Migration it compares the database schema with your models and sees that you've created a migration previously (201705171404346_Questionnaire) which has not yet been applied to the actual database. Because of this, the new migration can't determine what has changed in the schema when comparing the database.
Your options are:
Run Update-Database to apply the previous migration.
Delete the migration file 201705171404346_Questionnaire.cs and then run Add-Migration again which will contain both sets of changes.
Delete the entire database and all migration files, then run Add-Migration to create the initial schema.