Refactor repositories & database access to prepare for subscription#694
Conversation
antonymilne
left a comment
There was a problem hiding this comment.
Looks amazing, great set of changes! ⭐ I've left lots of questions just for my own understanding mainly.
Please could you remind me again why we want to change from one long running db session per server process to one session per query? Was it so that an update query can't interfere with a read one? Is there any performance hit due to the need to connect/disconnect from the db multiple times?
| def create_or_update_user_run_details( | ||
| self, updated_user_run_details: Dict | ||
| ) -> Optional[UserRunDetailsModel]: | ||
| with self._db_session_class.begin() as session: # type: ignore |
There was a problem hiding this comment.
Is there really no way in sqlalchemy to do an upsert more simply than this? 🤔 Seems odd.
There was a problem hiding this comment.
Yea I forgot why it was did this way. Let me double check
There was a problem hiding this comment.
Right, I remember now. SQLAlchemy has support for ON CONFLICT (although it's quite involved too), but only for the engine that supports it. SQLite doesn't: https://www.sqlite.org/lang_conflict.html, so we look before we leap :) The setattr could potentially be more readable if we spell out the properties. Let me do that.
There was a problem hiding this comment.
@AntonyMilneQB I have spelled out the properties and it's indeed more readable.
rashidakanchwala
left a comment
There was a problem hiding this comment.
LGTM! It work's well -- haven't come across any issues while testing.
I am still reviewing the PR from a learning purpose.
Co-authored-by: Antony Milne <49395058+AntonyMilneQB@users.noreply.github.com>
a949660 to
1054f6d
Compare


Description
This PR:
repositories.pyinto multiple modules, each containing one repository for easier maintanence.Development notes
QA notes
Checklist
RELEASE.mdfile