Oncall is a calendar tool designed for scheduling and managing on-call shifts. It can be used as source of dynamic ownership info for paging systems like http://iris.claims.
Hi, I have deployed Oncall to GCP and am using Cloud SQL as the MySQL DB. Everything works fine until I attempt to Preview a Schedule, which throws an Internal Server Error in the UI and the following error in the Python logs:
pymysql.err.InternalError: (1787, 'When @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1, the statements CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can be executed in a non-transactional context only, and require that AUTOCOMMIT = 1. These statements are also not allowed in a function or trigger because functions and triggers are also considered to be multi-statement transactions.')
It looks like the preview function relies on the existence of a temp table to be passed to the scheduler job, but would the SELECT query that's currently there be enough to pass over to the scheduler? Any guidance on how to work around this?
I see this is disabled in https://github.com/linkedin/oncall/pull/200 but wanted to leave this open so when this is revisited consideration is made for Cloud SQL and temporary table usage.
Hi, I have deployed Oncall to GCP and am using Cloud SQL as the MySQL DB. Everything works fine until I attempt to Preview a Schedule, which throws an
Internal Server Error
in the UI and the following error in the Python logs:pymysql.err.InternalError: (1787, 'When @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1, the statements CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can be executed in a non-transactional context only, and require that AUTOCOMMIT = 1. These statements are also not allowed in a function or trigger because functions and triggers are also considered to be multi-statement transactions.')
Looks like Temporary Tables are not allowed in GCP Cloud SQL: https://cloud.google.com/sql/docs/mysql/features#differences
It looks like the preview function relies on the existence of a temp table to be passed to the scheduler job, but would the SELECT query that's currently there be enough to pass over to the scheduler? Any guidance on how to work around this?