Migrate to using ORM for database calls
- Dominant language
- Python
- Stars
- 13
- Forks
- 17
- Avg merge
- 6h 59m
- Merged PRs (30d)
- 1
Description
> [!NOTE]
> Migrated from [augurlabs/augur#3327](https://github.com/augurlabs/augur/issues/3327)
> Originally opened by `@MoralCode` on 2025-10-22
---
Using the ORM tooling we already have would:
1. make the codebase easier to read/understand (a contributor just asked what the input format for augur's `insert_data` function is - and it seems to be flat json corresponding to the table columns of the relevant table)
https://github.com/chaoss/augur/blob/c5eeb072ae5c541e5fbb56295b3afab5dffaf4b0/augur/application/db/models/augur_data.py#L1146
https://github.com/chaoss/augur/blob/c5eeb072ae5c541e5fbb56295b3afab5dffaf4b0/augur/application/db/models/augur_data.py#L1097
https://github.com/chaoss/augur/blob/c5eeb072ae5c541e5fbb56295b3afab5dffaf4b0/augur/tasks/git/facade_tasks.py#L202
2. reduce instances where we are using 2-3 different methods of assembling DB queries (and sometimes multiple in the same call) - example: some of our raw SQL queries are assembled with python f-strings and others are done using the ORM prepared statements (and theres at least one place where we are doing BOTH in the same query).
3. probably provide some performance benefit for larger queries/bulk operations - by letting the ORM handle the actual creation of SQL to fetch or update data, we can potentially rely on code written by database experts, possibly improving performance and allowing us to remove custom code (like deadlock resolution) that we are doing ourselved using time-inefficient methods (i.e. calling `sleep()`)
Contributor guide
Assessment
This issue has not been assessed yet.