-
Notifications
You must be signed in to change notification settings - Fork 183
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
Trino demotion issue when moving between catalogs #3649
Comments
Thanks for reporting @MikeWallis42!
How was the view modified at this point? By who? |
I was unable to reproduce this. Assuming:
I created the following model:
Ran I then renamed it to
It was able to drop the table from I tried this with Now, I suspect your model was a bit more complicated than this so are you able to share the Also, echoing what @izeigerman mentioned - how was the view modified? Was it modified by SQLMesh or something else? |
Thank you for getting back to me! I'll spend a bit of time this morning trying to come up with a MRE. |
@MikeWallis42 did you manage to figure out a MRE for this issue? |
When promoting a model that has changed catalogs in Trino (in this example Hive -> Iceberg) we end up with an unsupported format error.
I think what's happening is that the new view is created in the new catalog using
CREATE OR REPLACE VIEW
during the promotion step.When it comes to demoting the old view in the old catalog this is then attempted using
DROP VIEW IF EXISTS
using the old catalog.By this point the view has already been modified to an Iceberg view and so Trino can't drop it when using the Hive catalog as they're different lower level APIs.
I think the root cause of the issue is that by changing the catalog which forms part of the name of the model, this then means that sqlmesh wants to create a new model and remove an old model.
If only the catalog has changed, in the case of Trino, we should only create the new model (promote) and not remove the old model (demote).
I suppose this only matters when both are using the same catalog (in this case Glue/HMS), if they were physically different databases then this wouldn't be an issue.
For the moment we're manually dropping views to get around the issue but when we move to production that becomes a bigger issue due to access constraints.
The text was updated successfully, but these errors were encountered: