CREATE OR REPLACE VIEW removes permissions [Unity Catalog]

[vmpmreistad]

When I run CREATE OR REPLACE VIEW on an existing view in Unity Catalog, the grants that were made on that object are removed. This seems like it is a bug. Is it on purpose or not?
How to replicate:
1. Create the view
Run the create or replace statement:
create or replace view bronze.default.test_access_view
as
select 1 as one;
2. Grant access to a user
Run a statement to grant access
grant select on bronze.default.test_access_view to `user1`
3. Verify that user has access to view
4. Rerun the create or replace view statement
create or replace view bronze.default.test_access_view
as
select 1 as one;
5. Check permissions
User1 does not have permission on the table anymore.The reason I suspect this is a bug is because if I run CREATE OR REPLACE TABLE instead of view, and follow the same exact procedures as above, then user1 does not lose access to the table afterwards.Is this a bug that can be fixed?

[marcell_nagy]

Hello @Retired_mod , you are wrong, this is a bug. I'll file an issue to remove this feature from Databricks. It can be of course possible to change only the definition/code of the view and do not touch or just copy the previous permissions. Permission management always had separated commands and UI tab, and it is very bad for CI/CD tasks, where alter view is not the same and thus not an alternative. Even if it relates to the create or replace view, Databricks SQL can create keywords to tell that when replacing the view, do not touch the permissions. Or just a command to refresh the code of the view. Maybe changing/keeping the permissions could be controlled under another permission. So there are lot of possibilities.

[gavinchi-onmo]

I've just encountered this exact same problem where the behaviour of CREATE OR REPLACE for Tables keeps the permissions but loses them for Views. Very frustrating as it creates a race condition within the CI/CD to resolve!

@marcell_nagy  or @vmpmreistad  did either of you ever get any response from Databricks on this being resolved?

[md1828459045]

Would also love any sort of communication back from Databricks on why create or replace view acts like this.

I have had to run my CICD once with create (or replace) and then make a code change to swap to "alter view," which per https://docs.databricks.com/aws/en/sql/language-manual/sql-ref-syntax-ddl-alter-view, 

>  is equivalent to a CREATE OR REPLACE VIEW statement on an existing view, except that privileges granted on the view are preserved.

It feels, sure...fine.  But our table/view creates are run in the same workflow as our ETL, and making me deploy through my environments with something I can only run once to then change and deploy again so that I can change the guts of my view is not ideal.