If initialize authorization fails for any reason, some remnants of the operation remain around. Once DDL_TRANSACTIONS have been enabled, then this issue goes away.
Code changes have been made as follows:
- If the initialize operation fails and DDL_TRANSACTIONS is not enabled, go ahead and cleanup all remnants of the operation.
- Added new option to cleanup after a failed authorization attempt: INITIALIZE AUTHORIZATION, CLEANUP. The CLEANUP option can be used to clean up after a failed initialize attempt when the DROP option fails.
- Added logging into the initialize, drop, and cleanup authorization requests.
Trafodion-1100 Creator of view in private schema unable to select from view For private schemas, all objects are owned by the schema owner. If an authID has create component privilege, they can create objects in other schemas. However, the owner of the new object is still the schema owner.
When the object creator is not the schema owner, then the schema owner automatically becomes the owner and the object creator is granted all relevant privileges on the object WGO.
For views, this was not working correctly.
Also found another issue where column privileges were not being handled correctly when generating the privileges list.
Problem is described in more detail in the JIRA
CmpSeabaseDDLview - changed the create view code to add privileges for both the schema owner and the view creator, and fixes the privilege list issue. PrivMgr - added a helper function to convert an authID to an authName PrivMgrCommands - changed the API to send in the grantor ID PrivMgrPrivileges - changed the code to use the passed in grantor TEST141 - added a new regression test, it is currently skipped until trafodion-1087 is resolved.