Open ravinggenius opened 2 months ago
I was messing around with my schema last night. Eventually I settled on an approach that allowed me to remove the dependent view (latest_versions
) and the dependency (depends_on = [view.latest_versions]
) altogether. However this is still an issue, as I still get the same error when trying to remove the dependency.
This would be a serious problem in production, requiring bailing out of declarative migrations in favor of versioned migrations. Honestly this is a bummer, as one of the things that initially attracted me to Atlas was the declarative migration management.
First I am very new to this project and even this approach to managing database migrations. (I started using atlas yesterday.) So far I'm very happy! I did a quick search for related issues. I found https://github.com/ariga/atlas/issues/1523, but I'm not sure if it's actually related or not. I apologize if this is a duplicate. By the way I am not a Go developer. I'm using atlas in a Node/Next project.
Background
I defined a
schema.hcl
file with a couple views in it (latest_versions
andversioned_items
). When I ran the migration, it errored because the views were re-ordered from the source I defined them in. Theversioned_items
depends onlatest_versions
. No worries as I found thedepends_on
option for definingversioned_items
. Here's the relevant portions from myschema.hcl
:Later I found I needed to a new field to
versioned_items
. I added the new field and re-ran atlas. Here's the diff:Issue
Here's the error I got:
Examining the planned changes made it obvious:
latest_versions
was dropped and recreated beforeversioned_items
was dropped and recreated. Here's the relevant portion of the planned changes:Solution?
I seems to me that edits to views should drop dependent views (recursively) before dropping the view being edited. This might result in some views being dropped/recreated multiple times, so maybe it would be best to drop all target views first, then recreate them.
In my case the planned changes should look like the following. Notice how views are dropped in reverse dependency order, then created in dependency order:
Alternatively the commands to
DROP
/CREATE
views should be wrapped in constraint defer commands so the database doesn't error out.Work-around
For now I can work around this issue by dropping my database and recreating it, as I haven't pushed any of these changes to production. However that wouldn't work if I had deployed to production between initially creating the views and later editing
versioned_items
.Edit: typo