Unable to <dropView> (view not found)

General Discussion
1
When I try to delete a view I get the following message:

2

For some reason, this problem went away: I ran into a lot of issues when trying to run the new changesets on PostgreSQL and after correcting all of the issues I was able to add the offending without any issues.

What I did

The error message came when I was trying to drop the userid column. Liquibase failed, because the userid colum was used by something else

I had already dropped the fk constraints from the column to userid in the users table

I dropped the index on the userid colum, then I got complaints from two other views using the column

I dropped the views (I was no longer using them anyway)

   

       

       

   

I now got an error message saying that the accounts_view was still using the column

I put in the that had failed earlier, and expected it to fail, except it didn’t

   

       

   

Now I could run the changelog on PostgreSQL without errors (including dropping the userid column from the accounts table), so I tried running it on derby, and this time removing the view didn’t fail

So I put in a new and updated view without the userid column and this worked fine

   

       

            select accounts.account_id, accounts.username, first_name, last_name, SUM(transaction_amount) as balance

            from users

            join accounts on accounts.username=users.username

            join transactions on transactions.account_id=accounts.account_id

            group by accounts.account_id, accounts.username, first_name, last_name

       

   

Now I’m trying to remove the view completely and I’m again told the view doesn’t exist

   

       

   

The accounts_view, with the new username column in the accounts table, obviously exists when code is running, if not, the code would have failed at an early stage

I thought it might have something to do with transactions used by the liquibase setup (when running in derby in memory, in test situations, I always set the database up from scratch) so I tried running the from a separate in a different file, but I still got the accounts_view not found

I added a conditional to the removing the accounts_view

   

Now I didn’t get any errors when running the in derby, but the count of sucessful changeSets stayed the same

I tried running the changelog in PostgreSQL again and here also it didn’t fail, but I found the following in the log

          db-changelog/db-changelog-1.0.0.xml : Not precondition failed

I thought it might have been the other blockers for removing userid that masked of accounts the first time I  tried, but now I don’t know what would be the candidates for such a masking? (I don’t know why the index on the userid column and the other two views would mask accounts_view in the first place)

Ideas?

3

Hm… when I look at the log output from the failing unit test it looks like runs without error.  Maybe I’ve been fooling myself (wouldn’t be the first time…):

INFO 3/30/19 11:26 AM: liquibase: Successfully released change log lock

4

I was indeed fooling myself, both the first time and now this time.  The failing unit test had the following code in it:

        }
Sorry about the noise!