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

drop_index not work on postgresql #459

Closed
OnePieceLv opened this issue May 16, 2021 · 3 comments · Fixed by #490
Closed

drop_index not work on postgresql #459

OnePieceLv opened this issue May 16, 2021 · 3 comments · Fixed by #490
Labels
bug An existing feature is not working as intended

Comments

@OnePieceLv
Copy link

Describe the bug
add an index to column success, but failed to drop the index when migrating rollback

To Reproduce
Steps to reproduce the behavior:

  1. create a migration file.
  2. add an index to the column in the up method
  3. execute migrate
  4. drop the same index in the down method
  5. execute migrate rollback. and failed

Expected behavior
drop_index generate sql ALTER TABLE table_name DROP CONSTRAINT table_name_column_index.
but in postgresql should be DROP INDEX table_name_column_index

Screenshots or code snippets
Failure
image.

Success
image

Desktop (please complete the following information):

  • OS: macOS
  • Version Big Sur

What database are you using?

  • Type: Postgres
  • Version 12.2
  • Masonite ORM v1.0.47
  • Docker Environment: Postgres Office Image (postgres:12.2)

Additional context
In the end, I execute the SQL statement DROP INDEX .... complete requirements

@OnePieceLv OnePieceLv added the bug An existing feature is not working as intended label May 16, 2021
@OnePieceLv
Copy link
Author

I execute command \d+ table_name. I can see the index
image

but I execute the SQL
SELECT * FROM information_schema.constraint_table_usage WHERE table_name = 'table_name'.
I don't see any related constraints

@josephmancuso
Copy link
Member

Looked into this issue. The problem is that currently the drop indexes and drop constraints are tied together in the Table class.

We are tying indexes in with unique constraints. Postgres treats these differently so we either need to somehow identify them or separate them out in the Table class and iterate through them differently in the platform classes.

@holic-cl
Copy link

I have same issue:

My Migration:

class AddIndexesToRelationships(Migration):
    def up(self):
        """
        Run the migrations.
        """
        with self.schema.table('branches') as table:
            table.index('code')

    def down(self):
        """
        Revert the migrations.
        """
        with self.schema.table('branches') as table:
            table.drop_index(['code'])

My database after run the migration:

opticks=# \d branches
                                        Table "public.branches"
   Column   |            Type             | Collation | Nullable |               Default                
------------+-----------------------------+-----------+----------+--------------------------------------
 id         | integer                     |           | not null | nextval('branches_id_seq'::regclass)
 code       | character varying(255)      |           | not null | 
 name       | character varying(255)      |           | not null | 
 created_at | timestamp without time zone |           |          | CURRENT_TIMESTAMP
 updated_at | timestamp without time zone |           |          | CURRENT_TIMESTAMP
Indexes:
    "branches_id_primary" PRIMARY KEY, btree (id)
    "branches_code_unique" UNIQUE CONSTRAINT, btree (code)
    "branches_code_index" btree (code)
Referenced by:
    TABLE "warehouses" CONSTRAINT "warehouses_branch_id_foreign" FOREIGN KEY (branch_id) REFERENCES branches(id)

The error i got:

  QueryException

  constraint "branches_code_index" of relation "branches" does not exist

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An existing feature is not working as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants