Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
The initial release of library management has been delivered to Trafodion. This is a follow-on JIRA that integrates library management operations into the existing Trafodion infrastructure. Currently, with the initial release of library management, the consumer needs to run a special script to set up everything. This JIRA will incorporate the steps into existing SQL commands and remove the need for the script.
To enable library management, a new schema is created. In the schema, a library and set of procedures are created. In addition, if authorization is enable, a new role is created and granted execute privileges (with grant option) on all procedures.
Integrating library management into Trafodion will be done by adding new options (create, drop, and upgrade) to the INITIALIZE TRAFODION command -
INITIALIZE TRAFODION, CREATE LIBRARY MANAGEMENT:
This command creates the SEABASE_LIBMGR_SCHEMA, creates the SEABASE_LIBMGR_LIBRARY, and creates all the procedures as described in the init_libmgmt.sh script.
• SEABASE_LIBMGR_SCHEMA is "LIBMGR"
• SEABASE_LIBMGR_LIBRARY is "DB__LIBMGRNAME"
(Note - SEABASE_LIBMGR_SCHEMA is set to "LIBMGR" instead of DB__LIBMGR. This name was chosen to meet current architecture standards for Trafodion. Any schema beginning and ending with an underscore is considered system system. System schemas are treated special – for example, a person cannot drop the schema or create their own private objects in the schema. We want this schema to be considered a system schema.)
If authorization is enabled, then role DB__LIBMGRROLE is granted execute privilege with the WITH GRANT OPTION on all procedures.
INITIALIZE TRAFODION, DROP LIBRARY MANAGEMENT:
This command drops the SEABASE_LIBMGR_SCHEMA.
INITIALIZE TRAFODION, UPGRADE LIBRARY MANAGEMENT:
This command verifies that the SEABASE_LIBMGR_LIBRARY exists and adds any new procedures. It will not drop or alter existing procedures.
Once we externalize these procedures, we cannot drop or alter them without some kind of upgrade operation. For example, if a user is actively using one of these procedures, dropping or changing them could cause the customer's application to fail. If you do need to change something like their signatures, it might be easier to add a new procedure. If you want to drop them, then we need some mechanism to "obsolete" them for a release or two before actually removing them.