Role | Assignee | Notes |
---|---|---|
Owner | Brent | |
Approver (project plan) | Kriti | Needs to approve project plan |
Approver (backend) | Brent | Needs to approve back end spec |
Contributor (requirements) | Brent | Creates product spec, requirements, GitHub issues |
Contributor (requirements) | Dom | Creates product spec, requirements, GitHub issues |
Contributor | Anish | Coding and reviewing |
Contributor | Dom | Coding and reviewing |
Contributor | Mukesh | Coding and reviewing |
Data Definition Language (DDL) operations are those that manipulate the actual data model on the database. Some relevant SQL words are CREATE
, ALTER
, and DROP
. These operations require knowledge of the database to do their work. E.g., a function must know the name of a table to ALTER
it. Our current architecture requires reflecting the state of the database into memory in Python, then manipulating that state’s representation in Python, then stamping that representation back down onto the database.
Our current setup for this is:
All of these problems are related to the fact that we’re building the SQL queries to run DDL operations in Python.
Create a function for each desired DDL operation on the database using SQL or PL/pgSQL.
Replace the current Python functions performing DDL operations with thin wrappers for these functions.
Refactor to remove SQLAlchemy objects from calls using Python DDL functions:
schema_name
, (schema_name, table_name)
, or (schema, table_name, column_name)
identifiers. Instead, prefer schema_oid
, table_oid
or (table_oid, attnum)
identifiers (may require modifying callers slightly, or scaffolding).Meta-issue tracking this project
Note: Parts of this timeline are delayed due to Brent’s parental leave.
Date | Outcome |
---|---|
2023-03-20 | Work starts |
2023-03-24 | Implementation spec and prototyping complete |
2023-03-31 | Implementation spec approved |
2023-04-28 | All needed DDL SQL Functions written |
2023-05-05 | All thin python wrappers written |
2023-05-12 | Refactor and clean up complete |