B/add synchronous job handler #756
Conversation
hyrisecockpit/database_manager/job/get_loaded_tables_in_database.py
Outdated
Show resolved
Hide resolved
hyrisecockpit/database_manager/job/get_loaded_tables_in_database.py
Outdated
Show resolved
Hide resolved
hyrisecockpit/database_manager/job/get_workload_tables_status.py
Outdated
Show resolved
Hide resolved
| return SqlResultInterface( | ||
| id=database_id, | ||
| successful=True, | ||
| results=[[str(col) for col in row] for row in cur.fetchall()], | ||
| results=[[str(col) for col in row] for row in results], |
There was a problem hiding this comment.
Still, why do we need the cast to str here?
There was a problem hiding this comment.
Inside the flask app, we are serializing and deserializing entities. We are doing that to make the code more robust. For example, if something changes in the response from the manager (database_manager/manager.py) we get an error. Inside the IPC communication, we are using the JSON form for the messages. So that's why we are serializing and deserializing entities. In the case of a SQL result, we expect it to be a string (because the frontend expects the same). That's why we cast it. The python entities are defined by a model in this case it is defined in:
https://github.com/hyrise/Cockpit/blob/dev/hyrisecockpit/api/app/sql/model.py
Inside the PR description of #775 I tried to describe how the serializing and deserializing is handled in our flask app.
hyrisecockpit/database_manager/job/get_loaded_tables_in_database.py
Outdated
Show resolved
Hide resolved
This PR is the third of four which aims to refactor the handling of Hyrise jobs (it aims to split #664). Hyrise jobs are interacting directly with the Hyrise to get the meta information and managing the Hyrise settings. We have three kinds of jobs:
Both continuous and asynchronous jobs are executed via the apscheduler (https://apscheduler.readthedocs.io/en/stable/). Esspacillay with the asynchronous jobs that's not necessary and increases the complexity (we could just use normal python threads). All three kinds of jobs are scattered in the database and background_scheduler component. The goal of the refactoring is now to have a clear separation for the jobs in the three categories (continuous, asynchronous, and synchronous) and define handlers for that. Moreover, we can stop the continuous jobs while loading/deleting tables (hyrise/hyrise#2180).
This PR implements the handler for the synchronous jobs.