I tried to build an Offer-Ready Docker container on Azure Cloud. Although I created a new (blank) table in PostgreSQL, I got this strange error message.
javax.servlet.ServletException: org.eclipse.jetty.servlet.ServletHolder$1: org.flywaydb.core.api.FlywayException: Found non-empty schema(s) "public" without schema history table! Use baseline() or set baselineOnMigrate to true to initialize the schema history table.
I double-checked the database, there is no table in schema "public". I didn't have that problem on AWS. Has anybody an idea what is different on Azure?
I had the same experience once.
The PostgreSQL database on Azure seemed empty (\dt returned no results),
But Flyway claimed the database was not empty (and therefore would not apply the migration scripts, for fear of interfering with whatever was already there).
Here is what I did was:
Create a new schema within the database e.g. myschema
Delete the default schema called public
Add the parameter currentSchema=myschema to the JDBC URL
And then it worked. I never got to find out what the root cause of this problem was.
EDIT: This link might provide more information on what objects are in the "public" schema by default on Azure PostgreSQL: https://community.atlassian.com/t5/Jira-questions/Re-quot-database-that-is-not-empty-quot-when-trying-to-use-azure/qaq-p/1308795/comment-id/410329#M410329
Related
I have a next.js app setup with prisma (v3.13) as the ORM. I am testing out bit.io for db hosting, and I am getting this error when trying to connect with the client. Everything works as intended when I use a local postgres db. I'm currently using a connection string that looks like the following:
DATABASE_URL="postgresql://[username]:[password]#db.bit.io/[username]/[dbname]"
I am trying to run prisma db push and getting the following error
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "eli-front/rankstl", schema "public" at "db.bit.io:5432"
Error: P1000: Authentication failed against database server at `db.bit.io`, the provided database credentials for `(not available)` are not valid.
Please make sure to provide valid database credentials for the database server at `db.bit.io`.
I am assuming the core of the issue has to due with the part of the error that says credentials for '(not available)' as if something isn't loading correctly.
Using the failing connection string with psql works completely fine, but not with prisma.
There are two things that need to be done in order for bit.io to work with Prisma.
Database names must be formatted as username.dbname rather than username/dbname. bit.io supports a number of different separator characters in the database name because different clients have different requirements around permissible characters in database names.
You have to create a second database on bit.io to use as a "shadow database." By default, this is done automatically—a shadow database is created, used, and deleted. However, most cloud database providers don't allow use of the CREATE DATABASE, so a shadow database must be created explicitly. See the prisma docs for details.
See the bit.io docs on connecting with Prisma for more details on setting up a minimum working connection.
I know this has been asked previously but I am spinning in circles here....
I have a postgres 14 database and a Springboot application running flyway-db:7.13.0 and flyway-core:8.5.10
I am using RDS. I created a new database manually using root account. When I run my springboot my flyway migration fails with the 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.
I understand the reason why this is happening but when I add the baselineVersion and baselineOnMigrate to my flyway gradle config it still doesn't work. I even added
flyway {
url = dbUrl
user = dbUser
password = dbPassword
schemas = ['public']
baselineVersion = '0.0'
baselineOnMigrate = true
locations = ["filesystem:${dbMigrationPath}"]
}
also I added
spring.flyway.baseline-on-migrate = true
to my application.properties
What confuses me the most is if I start the application pointing to the default postgres database with the root user. The migration works and it creates the flyway history table. but when I run it pointing to the newly created database it doesn't work.
Any idea?
I figured it out. It turned out I needed to add the baselineOnMigration flag to my configuration
Flyway.configure().baselineOnMigrate(true).dataSource(new TransactionAwareDataSourceProxy(dataSource)).load();
Whether to automatically call baseline when migrate is executed against a non-empty schema with no schema history
table. This schema will then be initialized with the baselineVersion before executing the migrations.
Only migrations above baselineVersion will then be applied.
This is useful for initial Flyway production deployments on projects with an existing DB.
Be careful when enabling this as it removes the safety net that ensures
Flyway does not migrate the wrong database in case of a configuration mistake! (default: false)
flyway.baselineOnMigrate=
flyway.baselineOnMigrate=true
I added flyway.baselineOnMigrate=true under the statement above and it worked.
I have created a Postgresql database A using liquibase changesets. Now, I'm creating an application that allows creating a new database B and copies the schema from database A in real-time including the liquibase changesets as the database can still be updated later. Note that at the time of the copied schema in database A could already be updated, making the base changesets outdated.
My main question would be:
How to copy PostgreSQL schema x from database a (dynamically generated at run-time) to b using liquibase? Database b could be on another server.
If it's not possible with liquibase, what other tools or approaches would make this possible?
--
Let me add more context:
We initialize a new database a schema using liquibase changeset.
We can add a new table and field to the database an at run-time. Or during the time when the application is running. For example, we add a new table people to the schema of database a, which is not originally in the changeset. This is done using liquibase classes too. So changeset is added to databasechangelog table.
Now, we create a new database b.
We want to import the schema of the database a to b, with people table.
I hope that is clear.
Thanks.
All schema changes must be run through your schema migration tool
The point of using a database schema migration tool such as Liquibase or Flyway is to have a “single source of truth” regarding the structure of your database tables. Your set of Liquibase changesets (or Flyway scripts) is supposed to be that single source of truth for your database.
If you are altering the structure of you database at runtime, such as adding a table named people, outside the scope of your migration tool, well, then you have violated the rules of the game. You will have defeated the purpose of using a schema migration tool. The intention of using a schema migration tool is that you make all schema changes through that tool.
If you need to add a table while running in production, you should be dropping the physical file for the Liquibase changeset (or Flyway script) into the file system of your database server environment, and then invoking Liquibase (or Flyway) to run a migration.
Perhaps you have been misunderstanding the sequence of events:
If you have built a database on server "A", that means you installed Postgres, created an empty database, then installed the collection of Liquibase changesets you have carefully built, then ran a Liquibase migration operation on that server.
When you go to create a database on server "B", you should be following the same steps: Install Postgres, create an empty database, installing the very same collection of Liquibase changesets, and then running a Liquibase migration operation.
Alternatively, if making a copy of server "A" to create server "B", that copy should include the exact same Liquibase changesets. So at the end of your copy process, the two databases+changesets are identical.
Here's how I solved this problem of mine using the Liquibase Java library:
1.) Export the changelog from the source database into a temporary file (XML).
Liquibase liquibase = new Liquibase(liquibaseOutFile.getAbsolutePath(), new FileSystemResourceAccessor(), sourceDatabase);
liquibase.generateChangeLog(catalogAndSchema, changeLogWriter, new PrintStream(liquibaseOutFile.getAbsolutePath()), null);
2.) Execute the temporary file to the new data source.
Liquibase targetLiquibase = new Liquibase(liquibaseOutFile.getAbsolutePath(), new FileSystemResourceAccessor(), targetDatabase);
Contexts context = new Contexts();
targetLiquibase.update(context);
Here's the complete code: https://czetsuya-tech.blogspot.com/2019/12/generate-postgresql-schema-using-java.html
I used prisma to generate the schema to a database, but due to changing an id column started getting errors. I deleted the tables and was going to redeploy the schema but I can't find a way to do that.
I've already tried doing things like prisma deploy, but it tells me I'm already sync'd up which isn't true. I need it to redeploy as if the schema was new and it seems to not want to do that.
TL;DR: Try prisma delete then prisma deploy.
Prisma create a database for management where it will hold all migration related data. Even if you deleted the tables manually, you didn't change the migration data about your service. Therefore, Prisma think everything is up-to-date.
Instead of manually deleting the tables, you should use prisma delete to let Prisma do a clean deleting of your tables. Then, you can re-run prisma deploy to rebuild the tables again.
Give this a try: "prisma deploy --force"
According to the documentation you have to accept data loss caused by schema changes with --force. But the tables are already deleted in your case, so I think it is ok to try it.
Prisma doc
I wanted to create a replicate of my production database for staging and created the staging DB instance from a production snapshot. However, this new instance still has the Database Name: "production-database". I was able to rename the database on PSQl to "staging-databse," but this is not reflected in the AWS Console. I'm afraid that future developers will be very confused, and was wonderign how to rename the "Database Name" on AWS?
Don't use the default database option. All it does is create a custom-named database by default. There may be uses for it, but I never use it, because it seems to serve no purpose at all other than to specify what the database that's created by default (when the instance is first created) will be named.
Database Name
If you want to specify a database name for the default database, type a name for your database of up to 63 alpha-numeric characters. If you do not provide a name, the default "postgres" database is created.
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreatePostgreSQLInstance.html
I assume this is intended to be a convenience for new RDS users, but to me, it seems unnecessary. It has no apparent impact on ongoing operation of the instance, which can, of course, have multiple independent databases on it.
This apparently can't subsequently be changed, so it's more of an annoyance than anything. I always leave this blank.
Not immediately obvious - when creating a new db expand the Additional Configuration card to create an initial db name
I created a new free tier instance for small scale testing and this is the DB name I see in my configuration:
I looked everywhere, but could not figure out what my database name is or how to create an initial database. Turns out the database name is postgres. It's also worth noting that I kept the default username, so in this case the username and database name are the same. If you changed the default username and postgres isn't working, maybe try using your username as your database name.