WL#7898: Use DD API to work with events
Affects: Server-8.0 — Status: Complete
WL#6388 provides new DD API to work with events. The scope of this Work Log (WL) task is: * Use new Data Dictionary (DD) dd::Event object and the related APIs for create, alter, drop and load events meta-information. Related Work Logs: WL#6388:- Define and Implement API for Events. WL#6391:- Hide DD system tables from users.
F-1: Boostrap procedure must not create mysql.event table. mysql.event table is created during initialize phase using the system script mysql_system_tables.sql. Modify this script to avoid creation of mysql.event table. F-2: Boostrap initialization phase of new DD code shall create the mysql.events table. With F-1 and F-2, event DD tables shall be hidden from users. (Please refer "WL#6391 - Hide DD System tables from user.") F-3: Create Event operation shall store metadata of Events in mysql.events meta table using New DD APIs and it's corresponding Dictionary object. F-4: Drop operation shall remove metadata relating to the Event for which drop operation is performed by using New DD APIs. F-5: Modification to Event related meta-information shall be performed using New Data Dictionary APIs. F-6: New DD API shall be used to fetch meta-information relating to Event. F-7: New DD API to fetch list of all event names and as well as events that fall under a particular schema shall be used to display information of all events/under a particular schema as well as drop all events that belong to a schema. F-8: Information Schema Events table shall fetch data by making using of the new DD API to show information that relate to Events. NF-1: Using new DD table and DD APIs should not have any effect on functional features of Events.
WL uses the new Data Dictionary (APIs) and Data Dictionary table Events provided by WL#6388 to create, drop , alter and load events metadata. Currently the events metadata is stored in mysql.event table (MyISAM). The current event subsystem directly write to mysql.event table by making use of the handler APIs. The worklog does the following things: A. Provide auxiliary APIs in dd namespace to create, drop, alter and load events that make use of the underlying dictionary client interface required to persist the meta information B. Make use of the auxiliary APIs in the existing Events subsystem server code to implement the Events operational functionality and the related modifications required to use the auxiliary APIs. This worklog will not make any major changes to the existing design of the Events subsystem in the server code. A: Auxiliary Support APIs in the dd namespace ---------------------------------------------- As part of this WL, the following support APIs are introduced to operate on DD tables using DD APIs. These methods are called by the Event subsystem of the server. 1. Get Event by Schema name and Event name - Acquire Schema object corresponding to schema name using dictionary client interface method acquire - Acquire Event object by Schema name and event name via the dictionary client interface method acquire. If this is successful, the method a pointer to the Event dictionary object else null - The dictionary client interface may result in deadlock or timeouts, the method will return true and the Event object shall be null. - If the Event object is acquired is successfully , the method return true and the pointer to Event object is available in parameter of the event object that is passed by reference. 2. Check Event Exists - The Check Event Exists method uses the Get Event method to acquire the pointer to the event object and thus check for it's existence. - The method returns false on operational errors such as deadlocks or timeouts that is possible. - If there is no operational error, the method returns true and if the event exists then it populates the passed in bool reference argument with true or else false 2. Create Event - Acquire schema object under which event to be created. - Invoke create event API provided by WL#6388. - Set the Event attributes using the Parsed Event data available. - Store the Event object by invoking the dictionary client interface. - Commit the transaction if the store succeeds or otherwise rollback. 3. Drop Event - Call drop event using the dictionary client interface to drop objects. - If the drop dictionary object call succeeds, commit the transaction else rollback. - Please note the caller of the drop event method shall check for existence of event. 4. Alter Event - Call Get Event by Schema name and Event name and obtain the handle to the Event object. - Modify the event attributes from the Parsed Event Data. - Call dictionary client interface update method. - If the above call succeeds, commit the transaction else rollback. 5. Drop all Events Under a Schema - Loop through list of all event objects under the schema using the iterator interface. - For each event obj, call the Drop Event method to drop the object corresponding to schema name and event name. - This used is while during drop databases. 6. Get Event Schema Name - This method tries to acquire schema name given a schema id. - Call uncached acquire to obtain the schema object corresponding to schema id. - Fill in the schema name from the schema object. - This method is used when during event initialization or retrieving event information for filling information schema. We usually iterate list of all events. During this phase, we retrieve schema id from event object and get corresponding schema name either for information purpose or destructive update like drop. 7. Update Event Time Fields - Get the handle to the event object using the event name and schema name. - Set the last executed and status attribute of the object. - Update the event dictionary object by calling dictionary object client interface. - If the above call succeeds, Type conversion to convert enum types between legacy enums and enums relate to Event object types in dd namespace. 1. Get Old Status: Convert DD event status to Legacy Event Status. 2. Get Enum Event Status: Convert Legacy Event status to DD Event status. 3. Get Old On Completion: Convert DD Event On Completion type to Legacy On Completion type. 4. Get On Completion: Convert Legacy on completion to DD Event on completion. 5. Get Old Interval Type: Convert Interval type of DD Event (known as Interval Field) to Legacy Interval type. to 6. Get Enum Interval Field: Convert Legacy Interval field to DD Event Interval Type (aka known in DD as Interval Field) B: Modifications in the Event subsystem of server code: There would be no major changes in the except instead of direct handler calls that fetch data related to event in the event subsystem shall be handled by dd auxiliary APIs explained in A above. The Event_db_repository class abstracts the details of communication underlying storage layer to fetch meta information in the current Event Design. They implement nearly the same method as explained in A above and use the handler calls correctly. This class along with it's methods shall be retained and will serve as the adapter to fetch the related meta information. This class method is modified to make use of the DD auxiliary API to fetch information. The find_named_event of this class is removed and we use the dd::event_exists directly in various class method APIs as and when required. There is a runtime hierarchy of classes that derive from Event_basic and this include the Event_timed, Event_job_data and Event_queue_element. All of this has various event related attributes some of them normalized plus additional attributes with clear defined functionalities required for runtime event operational semantics. Currently all of them have a implement the virtual load_from_row that fill in the necessary attribute by fetching information directly from the table via the load_named_event method of the Event_db_repository. This load_from_row method is replaced by fill_event_info that shall take an event object and fill out the necessary attributes required for operational semantics of these classes. This design choice keeps the existing events class design clean and maintains the original design and is optimal in terms of management and ownership of the Event information. C: User-noticeable Changes: 1. User need not do any implicit LOCK TABLE to operate/manipulate/use Event related things. Direct access to the Events meta table is disallowed. 2. MDL locks are acquired for doing event related functionality including read operation. This methods provides general correctness and serialized view of concurrent operations among concurrent users using the events functionality. 3. This WL shall remove mysql.event table and provides new meta table mysql.events and the structure of column name and their types is a little bit different from mysql.event. This will have some impact on user land tools like mysqlupgrade and privileges which shall be taken care by other relevant worklogs:
Copyright (c) 2000, 2020, Oracle Corporation and/or its affiliates. All rights reserved.