| 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 Manipulation Language (DML) operations are those that manipulate the data stored in a database. Some relevant SQL words are UPDATE, INSERT, and DELETE. These operations require knowledge of the database to do their work. E.g., a function must know the name of a table to INSERT into it. Our current architecture requires reflecting the state of the database into memory in Python and using that state to build INSERT queries and the like.
Our current setup for this is:
All of these problems are related to the fact that we’re building the SQL queries to run DML operations in Python.
Create a function for each desired DML operation on the databse using SQL or PL/pgSQL.
Replace the current Python functions performing DML operations with thin wrappers for these functions.
Refactor to remove SQLAlchemy objects from calls using Python DML 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).TODO
Note: Parts of this timeline are delayed, since they’re blocked by the removal of DDL, and Brent’s parental leave.
| Date | Outcome |
|---|---|
| 2023-03-20 | Prototyping work starts |
| 2023-04-28 | Implementation spec and prototyping complete |
| 2023-05-05 | Implementation spec approved |
| 2023-05-12 | All needed DML SQL Functions written |
| 2023-05-19 | All thin python wrappers written |
| 2023-05-26 | Refactor and clean up complete |