Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean tries to drop a function from an extension and fails #100

Closed
flyway opened this issue Jun 25, 2013 · 53 comments
Closed

Clean tries to drop a function from an extension and fails #100

flyway opened this issue Jun 25, 2013 · 53 comments

Comments

@ghost
Copy link
Collaborator

@ghost ghost commented Jun 25, 2013

Original author: Martin.A...@gmail.com (May 11, 2012 10:11:31)

We are using PostgreSQL 9.1 and are using the uuid-ossp extension. Clean tries to drop one of its functions. The extension has been installed manually as it required adding binaries to the DBMS.

Any way to work around this?

FlywayException: Error executing statement at line 64: DROP FUNCTION IF EXISTS "public"."uuid_nil"() CASCADE
Occured in com.googlecode.flyway.core.migration.sql.SqlStatement in method execute, line number 78
Caused by org.postgresql.util.PSQLException: ERROR: cannot drop function uuid_nil() because extension uuid-ossp requires it
Hint: You can drop extension uuid-ossp instead.
Occured in org.postgresql.core.v3.QueryExecutorImpl in method receiveErrorResponse, line number 2102

Original issue: http://code.google.com/p/flyway/issues/detail?id=257

@ghost
Copy link
Collaborator Author

@ghost ghost commented Jun 25, 2013

From axel.fontaine.business@gmail.com on May 22, 2012 00:08:11
Hi Martin,

thanks for your report. Sorry for the late reply. I've thought about this a bit.

Do you believe the following solution would work?

  • Add support to Flyway to clean extension (using DROP EXTENSION)
  • Add a CREATE EXTENSION line to your initial migration

Looking forward to your feedback
Axel

P.S.: There are 2 things that still would need to be researched: how to do this with 9.0 and how to enumerate the installed extensions.

@ghost
Copy link
Collaborator Author

@ghost ghost commented Jun 25, 2013

From Martin.A...@gmail.com on May 22, 2012 20:15:00
Looks like a feasible solution. Let me explain what actions we took when establishing our migration using the extension.
1.) The uuid-ossp extension requires a binary/os-specific addon. On the windows platform that was already installed. For linux we had to get the package first and install it
2.) Since the extension required some additional software to be installed we decided not to have the CREATE EXTENSION statement as part of the migration script

Still the cleanup tries to delete individual functions from the extension. So either during cleanup functions from extensions are left alone or only a drop extension command is executed.

@ghost
Copy link
Collaborator Author

@ghost ghost commented Jun 25, 2013

From Martin.A...@gmail.com on May 29, 2012 20:15:21
As we are currently looking for a workaround for the failing clean process, we have a question regarding the reason why clean is actually performing a 'object by object' delete process?
How much would it differ from a simple DROP SCHEMA, CREATE SCHEMA sequence?

@ghost
Copy link
Collaborator Author

@ghost ghost commented Jun 25, 2013

From axel.fontaine.business@gmail.com on June 04, 2012 19:12:18
Hi Martin,

I've added the answer to your question to the FAQ: http://code.google.com/p/flyway/wiki/FAQ?ts=1338836686&updated=FAQ#Why_does_clean_drop_individual_data_objects_instead_of_the_schem

I have been pondering the question of leaving functions from extensions alone vs drop extension. I am still undecided. I currently lean towards the latter as the former would invalidate the promise to truly clean the schema of all its objects. The disadvantage of this is of course the required introduction of separate cleaning methods for 9.0 and 9.1.

Input and/or contributions welcome.

Cheers
Axel

@ghost
Copy link
Collaborator Author

@ghost ghost commented Jun 25, 2013

From kevin...@gmail.com on February 11, 2013 16:44:49
Doing DROP/CREATE SCHEMA may be useful for some situations, but there are many extensions which require superuser privileges to install/remove (e.g. isn), and others which do not require superuser may still be managed by a database administrator team which would prevent application developers (or the application user) from modifying them.

A local modification that I am using is to only drop objects when running as superuser or when the object is owned by the user (since the drop would fail otherwise and the object is not likely to be part of the migration).

The solution is not perfect. It may surprise users if some objects are left installed. This could, perhaps, be more transparent if a warning was issued or if it required a configuration option (dropObjects/dropOwnObjects/dropAllObjects or similar).

@ghost
Copy link
Collaborator Author

@ghost ghost commented Jun 25, 2013

From kevin...@gmail.com on February 11, 2013 16:45:40
Sorry, in my last comment I meant DROP/CREATE EXTENSION rather than DROP/CREATE SCHEMA.

@ghost
Copy link
Collaborator Author

@ghost ghost commented Jun 25, 2013

From laser.ta...@googlemail.com on March 08, 2013 21:59:35
Hi there, is there any solution yet?

I have the same problem with the extension postgis, which creates a table.
So when running clean the table cannot be dropped because postgis extension is still enabled...

@ghost
Copy link
Collaborator Author

@ghost ghost commented Jun 25, 2013

From axel.fontaine.business@gmail.com on March 12, 2013 09:57:28
No solution yet.

Somehow I feel that the best solution/workaround involves putting your objects in your own schema, so extensions don't interfere and Flyway doesn't have to deal with them.

Comments/contributions/pull requests welcome.

@wilkko
Copy link

@wilkko wilkko commented Oct 23, 2013

+1 for cleaning the schema of all its objects

@bjhartin
Copy link

@bjhartin bjhartin commented Nov 12, 2013

I have submitted pull request #629, which would allow us to extend any of the DbSupport classes. This makes it trivial to override doClean(), as demonstrated by the 'CustomCleanTest' in the core module.

@sfitts
Copy link

@sfitts sfitts commented Jul 21, 2014

Just ran into this when adding Postgres support. Surprised that there is still no solution.

@cowwoc
Copy link

@cowwoc cowwoc commented Sep 16, 2014

@axelfontaine I think @bjhartin might have dropped out and I agree with @sfitts that this issue is very annoying while doing Postgres development.

Any chance you could take another look at it?

@svmehta
Copy link

@svmehta svmehta commented Oct 3, 2014

+1

@cowwoc
Copy link

@cowwoc cowwoc commented Oct 7, 2014

@axelfontaine

I used callbacks to work around this issue (thank you!)

Just a head's up... Even once you fix this problem (dropping extensions), you'll also need to ensure you drop views before attempting to drop "basic types". Otherwise you'll get another error.

For those of you wanting to implement your own workaround, please see #629 (comment)

@marcomorain
Copy link

@marcomorain marcomorain commented Nov 15, 2014

👍

@rdifalco
Copy link

@rdifalco rdifalco commented Dec 1, 2014

I am having this problem. I have a migration that adds an extension for pg_trgm. Then I'm dead in the water for unit testing when I call flyway.clean(). What is the current workaround for this?

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Dec 1, 2014

Put your own objects in a different schema than public
Am 01.12.2014 21:20 schrieb "Robert DiFalco" notifications@github.com:

I am having this problem. I have a migration that adds an extension for
pg_trgm. Then I'm dead in the water for unit testing when I call
flyway.clean(). What is the current workaround for this?


Reply to this email directly or view it on GitHub
#100 (comment).

@rdifalco
Copy link

@rdifalco rdifalco commented Dec 1, 2014

Sorry Axel, I don't know what that means. Do you mean take "CREATE EXTENSION pg_trgm" out of my flyway migration file and do it manually?

@cowwoc
Copy link

@cowwoc cowwoc commented Dec 1, 2014

@rdifalco See #100 (comment) for a workaround. You register a FlywayCallback with Flyway, then implement beforeClean() to drop the function before Flyway tries to drop it itself.

@marcomorain
Copy link

@marcomorain marcomorain commented Dec 1, 2014

Is there a way to implement a callback with an SQL file rather than in Java?

@cowwoc
Copy link

@cowwoc cowwoc commented Dec 1, 2014

@marcomorain This is only possible in Flyway 3.1. See #728

@marcomorain
Copy link

@marcomorain marcomorain commented Dec 1, 2014

I'll give that a try when I get a change. Thanks.

On Mon, Dec 1, 2014 at 1:11 PM, cowwoc notifications@github.com wrote:

@marcomorain https://github.com/marcomorain This is only possible in
Flyway 3.1. See #728 #728


Reply to this email directly or view it on GitHub
#100 (comment).

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Dec 3, 2014

Let's revisit this for 3.2

This could be a starting point: http://stackoverflow.com/questions/25387168/how-to-find-all-user-defined-not-extension-related-functions-in-postgresql

Pull request or sponsoring welcome.

@imjoshholloway
Copy link

@imjoshholloway imjoshholloway commented Apr 16, 2015

Just incase someone comes looking here and doesn't fancy jumping between the issues to figure out a work around:

Create a beforeClean.sql file in your migrations folder and add the required DROP... command into it.

For example, if like me, when doing flyway clean -X you get: ERROR: cannot drop function uuid_nil() because extension uuid-ossp requires it you would add the following into the beforeClean.sql file:

DROP EXTENSION IF EXISTS "uuid-ossp" CASCADE;
@axelfontaine axelfontaine modified the milestones: Flyway 5.0, Flyway 4.1 Feb 1, 2017
@smrnv
Copy link

@smrnv smrnv commented Feb 8, 2017

+1

1 similar comment
@b0dh1
Copy link

@b0dh1 b0dh1 commented Feb 9, 2017

+1

@matsandreassen
Copy link

@matsandreassen matsandreassen commented Aug 24, 2017

+1

Just attempted to use Flyway with a PostGIS-enabled database in an integration test. Cleaning fails with:

org.flywaydb.core.internal.dbsupport.FlywaySqlException:
Unable to drop "public"."spatial_ref_sys"

SQL State : 2BP01
Error Code : 0
Message : ERROR: cannot drop table spatial_ref_sys because extension postgis requires it
Hint: You can drop extension postgis instead.

@ttaranov
Copy link

@ttaranov ttaranov commented Sep 17, 2017

+1, same as above - clean doesn't work with Postgres databases with PostGIS extension installed.

@matsandreassen
Copy link

@matsandreassen matsandreassen commented Sep 17, 2017

The reason we're encountering this is because we put our tables inside "public". There's a workaround to this which I've "uncovered" on Stackoverflow and the like. I'll try to re-iterate the solution:

  1. Create new schema. E.g. "myschema"
  2. To enable PostGIS extension on "myschema", execute:
    ALTER DATABASE <YOUR_DATABASE> SET search_path = myschema, public;
    ALTER USER <YOUR_USER> SET search_path = myschema, public;
  3. Ensure all your migrations create tables in "myschema".
  4. Finally, and I'm not sure why right now, Flyway does not seem to honor the schema setting in your jdbc-url. E.g. jdbc:postgresql://locahost:5432/mydb?currentSchema=myschema
    I came over this script (pretty sure it was on Stackoverflow):

Put in 'beforeEachMigrate.sql' on your migration path:

DO $$
DECLARE
default_search_path TEXT := NULL;
BEGIN
SELECT setting_value INTO default_search_path
FROM (
SELECT
substring(setting from 1 for eq_position - 1) AS setting_name,
substring(setting from eq_position + 1) AS setting_value
FROM (
SELECT position('=' in setting) AS eq_position, setting
FROM (
SELECT UNNEST(setconfig) AS setting FROM pg_db_role_setting s JOIN pg_database d ON s.setdatabase = d.oid WHERE d.datname = current_database()
) raw_db_role_settings
) presplit_db_role_settings
) split_db_role_settings
WHERE setting_name = 'search_path';

IF default_search_path IS NOT NULL THEN
EXECUTE 'SET search_path = '||default_search_path;
END IF;
END;
$$

Took me a while to figure this out but this solution seems to have no side effects. :)

@foal
Copy link

@foal foal commented Oct 19, 2017

I had the same issue with hstore extension (required superuser). Just create it in PG_CATALOG schema while setup test database as superuser.

CREATE EXTENSION hstore SCHEMA pg_catalog

In that case no need to set up search_paht.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Feb 18, 2018

This is now working as expected. As long as you create your extensions with CREATE EXTENSION IF NOT EXISTS you should now be able to clean your schema and rebuild it just fine.

@maraswrona
Copy link

@maraswrona maraswrona commented Mar 26, 2018

@axelfontaine unfortunately this is still not working for me. My setup:

flyway version: tried both 5.0.7 (recent) and 3.2.1 (embedded in spring boot)

V1__init.sql:

CREATE EXTENSION IF NOT EXISTS postgis;

CREATE TABLE mytable (
    id SERIAL PRIMARY KEY,    
    location geometry NOT NULL    
);

Then running against clean db:

$ ./flyway migrate
Flyway Community Edition 5.0.7 by Boxfuse

Database: jdbc:postgresql://localhost:5432/airlydb (PostgreSQL 9.5)
Successfully validated 1 migration (execution time 00:00.009s)
Creating Schema History table: "public"."flyway_schema_history"
Current version of schema "public": << Empty Schema >>
Migrating schema "public" to version 1 - init
Successfully applied 1 migration to schema "public" (execution time 00:00.900s)

And then:

$ ./flyway clean -X
Flyway Community Edition 5.0.7 by Boxfuse

DEBUG: Java 1.8.0_152 (Oracle Corporation)
DEBUG: Windows 10 10.0 amd64

DEBUG: Loading config file: C:\dev\apps\flyway-5.0.7\conf\flyway.conf
DEBUG: Unable to load config file: C:\Users\m.woroniecki\flyway.conf
DEBUG: Unable to load config file: C:\dev\apps\flyway-5.0.7\flyway.conf
DEBUG: Using configuration:
DEBUG: flyway.jarDirs -> C:\dev\apps\flyway-5.0.7\jars
DEBUG: flyway.password -> *****
DEBUG: flyway.url -> jdbc:postgresql://localhost:5432/airlydb
DEBUG: flyway.user -> postgres
DEBUG: flyway.locations -> filesystem:C:\dev\apps\flyway-5.0.7\sql
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\derby-10.12.1.1.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\derbyclient-10.12.1.1.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\h2-1.4.196.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\hsqldb-2.4.0.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\jtds-1.3.1.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\mariadb-java-client-2.2.0.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\mssql-jdbc-6.2.2.jre7.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\postgresql-42.1.4.jre6.jar
DEBUG: Adding location to classpath: C:\dev\apps\flyway-5.0.7\drivers\sqlite-jdbc-3.20.1.jar
Database: jdbc:postgresql://localhost:5432/airlydb (PostgreSQL 9.5)
DEBUG: DDL Transactions Supported: true
DEBUG: Schema: public
DEBUG: Spring Jdbc available: false
DEBUG: Scanning for SQL callbacks ...
DEBUG: Scanning for filesystem resources at 'C:/dev/apps/flyway-5.0.7/sql' (Prefix: '', Suffixes: '.sql')
DEBUG: Scanning for resources in path: C:\dev\apps\flyway-5.0.7\sql (C:/dev/apps/flyway-5.0.7/sql)
DEBUG: Filtering out resource: C:\dev\apps\flyway-5.0.7\sql\put-your-sql-migrations-here.txt (filename: put-your-sql-migrations-here.txt)
DEBUG: Found filesystem resource: C:\dev\apps\flyway-5.0.7\sql\V1__init.sql
DEBUG: Cleaning schema "public" ...
DEBUG: Rolling back transaction...
DEBUG: Transaction rolled back
ERROR: Unexpected error
org.flywaydb.core.internal.exception.FlywaySqlException:
Unable to drop "public"."spatial_ref_sys"
-----------------------------------------
SQL State  : 2BP01
Error Code : 0
Message    : ERROR: cannot drop table spatial_ref_sys because extension postgis requires it
  Wskaz▒wka: You can drop extension postgis instead.

        at org.flywaydb.core.internal.database.SchemaObject.drop(SchemaObject.java:83)
        at org.flywaydb.core.internal.database.postgresql.PostgreSQLSchema.doClean(PostgreSQLSchema.java:86)
        at org.flywaydb.core.internal.database.Schema.clean(Schema.java:149)
        at org.flywaydb.core.internal.command.DbClean$4.call(DbClean.java:179)
        at org.flywaydb.core.internal.command.DbClean$4.call(DbClean.java:176)
        at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:75)
        at org.flywaydb.core.internal.command.DbClean.cleanSchema(DbClean.java:176)
        at org.flywaydb.core.internal.command.DbClean.clean(DbClean.java:124)
        at org.flywaydb.core.Flyway$3.execute(Flyway.java:1306)
        at org.flywaydb.core.Flyway$3.execute(Flyway.java:1299)
        at org.flywaydb.core.Flyway.execute(Flyway.java:1655)
        at org.flywaydb.core.Flyway.clean(Flyway.java:1299)
        at org.flywaydb.commandline.Main.executeOperation(Main.java:157)
        at org.flywaydb.commandline.Main.main(Main.java:108)
Caused by: org.postgresql.util.PSQLException: ERROR: cannot drop table spatial_ref_sys because extension postgis requires it
  Wskaz▒wka: You can drop extension postgis instead.
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2477)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2190)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
        at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
        at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
        at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:158)
        at org.flywaydb.core.internal.util.jdbc.JdbcTemplate.execute(JdbcTemplate.java:246)
        at org.flywaydb.core.internal.database.postgresql.PostgreSQLTable.doDrop(PostgreSQLTable.java:43)
        at org.flywaydb.core.internal.database.SchemaObject.drop(SchemaObject.java:81)
        ... 13 more

You said

This is now working as expected. As long as you create your extensions with CREATE EXTENSION IF NOT EXISTS you should now be able to clean your schema and rebuild it just fine.

Could you provide a working example please?

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Mar 26, 2018

@maraswrona Check the milestone set for this issue. The fix is in the latest sources.

@maraswrona
Copy link

@maraswrona maraswrona commented Mar 26, 2018

ah.... so I guess the fix will be in the next release? Thanks for the clarification.

@hgl
Copy link

@hgl hgl commented Apr 16, 2018

Does the fix work with users without superuser privilege?

Sorry if I could just build from source myself and find out, but I'm not familiar with java, have no idea how to build 5.1.0 from github source.

@silentsnooc
Copy link

@silentsnooc silentsnooc commented May 11, 2018

This is not working for me either.

I am using

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
</dependency>
<dependency>
    <groupId>org.flywaydb.flyway-test-extensions</groupId>
    <artifactId>flyway-spring-test</artifactId>
    <version>5.0.0</version>
    <scope>test</scope>
</dependency>

or

[INFO] +- org.flywaydb:flyway-core:jar:5.0.7:compile
[INFO] +- org.flywaydb.flyway-test-extensions:flyway-spring-test:jar:5.0.0:test

in a Spring Boot (2.0.1.RELEASE) application. However, running my unit tests will throw:

org.flywaydb.core.internal.exception.FlywaySqlException: 
Unable to clean schema "public"
-------------------------------
SQL State  : 2BP01
Error Code : 0
Message    : ERROR: cannot drop type cube because extension cube requires it
  Hint: You can drop extension cube instead.


	at org.flywaydb.core.internal.database.Schema.clean(Schema.java:151)
	at org.flywaydb.core.internal.command.DbClean$4.call(DbClean.java:179)
	at org.flywaydb.core.internal.command.DbClean$4.call(DbClean.java:176)
	at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:75)
	at org.flywaydb.core.internal.command.DbClean.cleanSchema(DbClean.java:176)
	at org.flywaydb.core.internal.command.DbClean.clean(DbClean.java:124)
	at org.flywaydb.core.Flyway$3.execute(Flyway.java:1306)
	at org.flywaydb.core.Flyway$3.execute(Flyway.java:1299)
	at org.flywaydb.core.Flyway.execute(Flyway.java:1655)
	at org.flywaydb.core.Flyway.clean(Flyway.java:1299)
	at org.flywaydb.test.FlywayTestExecutionListener.dbResetWithAnnotation(FlywayTestExecutionListener.java:378)
	at org.flywaydb.test.FlywayTestExecutionListener.handleFlywayTestAnnotationForClass(FlywayTestExecutionListener.java:178)
	at org.flywaydb.test.FlywayTestExecutionListener.beforeTestClass(FlywayTestExecutionListener.java:157)
	at org.springframework.test.context.TestContextManager.beforeTestClass(TestContextManager.java:215)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:60)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: org.postgresql.util.PSQLException: ERROR: cannot drop type cube because extension cube requires it
  Hint: You can drop extension cube instead.
	at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2477)
	at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2190)
	at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
	at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
	at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
	at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
	at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:158)
	at com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)
	at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute(HikariProxyPreparedStatement.java)
	at org.flywaydb.core.internal.util.jdbc.JdbcTemplate.execute(JdbcTemplate.java:246)
	at org.flywaydb.core.internal.database.postgresql.PostgreSQLSchema.doClean(PostgreSQLSchema.java:90)
	at org.flywaydb.core.internal.database.Schema.clean(Schema.java:149)
	... 22 more
@silentsnooc
Copy link

@silentsnooc silentsnooc commented May 11, 2018

@axelfontaine Oh I only just saw your comment: Is it not supposed to work with 5.0.7?

@silentsnooc
Copy link

@silentsnooc silentsnooc commented May 11, 2018

Okay, I'll repeat what @foal said because it's easily overlooked.

If you can, just install your extensions with pg_catalog. In my case I put

CREATE EXTENSION IF NOT EXISTS cube WITH SCHEMA pg_catalog;
CREATE EXTENSION IF NOT EXISTS earthdistance WITH SCHEMA pg_catalog;

in my V1__init.sql script.

Now my tests are running without problems.

@zarinfam
Copy link

@zarinfam zarinfam commented Jun 26, 2018

I had this problem for test environment, see this answer https://stackoverflow.com/questions/46656531#51038385

@svpace
Copy link

@svpace svpace commented Dec 2, 2018

@axelfontaine perhaps I'm doing something wrong here but with flyway-core-5.2.1 and "create extension if not exists" on public (not pg_catalog) and I'm still getting the "ERROR: cannot drop table spatial_ref_sys because extension postgis ..." error on clean.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Dec 3, 2018

@svpace Please open a new issue with exact steps how to reproduce.

@flyway flyway locked as resolved and limited conversation to collaborators Dec 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.