Table Monitor Guide
Basic usage of the three table monitor types
Basic usage of the three table monitor types
The following is an excerpted tutorial, extracted from a complete example using the Python Table Monitor API, demonstrating the basic use of the three table monitor types:
The table monitors will be managed via instances of the GPUdbTableMonitor.Client class, which can create, process, & remove table monitors.
The prerequisites for running the table monitor example are listed below:
The native Kinetica Python API is accessible through the following means:
The Python package manager, pip, is required to install the API from PyPI.
Install the API:
|
|
Test the installation:
|
|
If Import Successful is displayed, the API has been installed as is ready for use.
In the desired directory, run the following, but be sure to replace <kinetica-version> with the name of the installed Kinetica version, e.g., v7.2:
|
|
Change directory into the newly downloaded repository:
|
|
In the root directory of the unzipped repository, install the Kinetica API:
|
|
Test the installation (Python 2.7 (or greater) is necessary for running the API example):
|
|
In this example, a set of batches of randomly-generated weather data for a fixed set of cities will be inserted into a "history" table. A table monitor client (via GPUdbTableMonitor.Client) will be created to watch for those newly inserted records and update a "status" table of those cities with their latest randomly-generated temperature values.
Afterwards, a set of updates will be made to the "status" table, followed by a set of deletes. A second table monitor client will be created to watch for these two event types and output the numbers of records updated & deleted to the console.
There are four main components involved in this example:
The key parts of table monitor processing via Python are:
The first step is to import Kinetica libraries, aliasing some of the classes for ease of use. Other supporting libraries need to be imported, as well.
|
|
Next, create a connection to Kinetica.
|
|
Then, subclass GPUdbTableMonitor.Client, the table monitor client class, and configure it to monitor the "history" table, which will use the connection to manage the table's monitor as well as process the insert events on it.
|
|
Create a list of callback types to use when monitoring the "history" table.
|
|
Initialize the class via the parent, passing the name of the table to monitor, the callback type list, and a list of options. Also, grab a handle to the "status" table for issuing updates.
|
|
Define the callback function that will be used by the table monitor client, which will update the "status" table with new "history" table records.
|
|
Define a second table monitor client, this time for monitoring updates & deletes on the "status" table.
|
|
Create a list of callback types to use when monitoring the "status" table.
|
|
Initialize the class via the parent, passing the name of the table to monitor, the callback type list, and a list of options. Also, grab a handle to the "status" table for outputting records after each update/delete.
|
|
Define one callback function for updates and one for deletes that will be used by the table monitor client. Each of these will output their respective event counts and output the full set of records from the "status" table.
|
|
|
|
Lastly, define the show_status function that will be called by each event handler to output the records in the "status" table.
|
|
After the table monitor clients have been created, confirm this by looking up the table monitors attached to the "history" & "status" tables and display the monitored event and event topic ID for each table monitor the tables have.
|
|
|
|
To start the table monitor clients, instantiate each container class with a handle to the database and call their respective start functions.
|
|
To stop and remove the table monitor clients (and their corresponding managed table monitors), call their respective stop functions.
|
|
Included below is a complete example of the Python Table Monitor API, containing all of the above code samples, as well as the loading of data into the "history" & "status" tables and the verification output of records.
To run the complete sample, ensure the table_monitor.py
file is in the
current directory, and do the following:
|
|
Note
As this script creates a schema and several database objects within it, system admin permission is required to run it.