-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Introduce repository pattern to prepare adding other database providers #646
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Someone is attempting to deploy a commit to the Quivr-app Team on Vercel. A member of the Team first needs to authorize it. |
Cant wait to see the end :) |
5366562
to
34aad24
Compare
@Noezor, great idea !! Feel free to add the SQL alchemy repository in backend/core/repository/SQLAlchemy. We're slowly trying to move all dependancy to supabase to core/repository/Supabase. The idea is to have repository functions that are agnostic from the database. |
Work has been moved to raoufchebri#1 The current solution is that we want to keep the |
Abstract Supabase from database query calls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The return values are not typed. Today, Supabase does not always return objects that are mappable directly to existing defined objects. We may want to add some level of normalization in the repository to make sure the return types always match and avoid doing repository-custom logic out of them. WDYT @StanGirard @gozineb ?
backend/models/brains.py
Outdated
.execute() | ||
) | ||
return [item["brains"] for item in response.data] | ||
return self.commons["db"].get_user_brains(user_id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We follow the use of commons here, but I am not sure pushing the db object in a dict enables the VSCode python server to be helpful and know the type of the variable?
We should use the typing of the Repository
in another MR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gozineb actually I noticed that for the other items on commons
, my VSCode does not seem to be able to infer a type, even though we have CommonsDep = Annotated[dict, Depends(common_dependencies)]
below. WDYT of having an explicit Dataclass CommonsDep
instead of resolving the types ad-hoc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree 44c6a2a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Noezor really like it, super clean !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keeping this for another PR, wdyt about the current state of this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are conflicts that needs to be fixed before merging @Noezor ;)
backend/routes/chat_routes.py
Outdated
commons["supabase"].table("chats").delete().match( | ||
{"chat_id": chat_id} | ||
).execute() | ||
commons["db"].delete_chat |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Method is not called here
@Noezor @raoufchebri any update or help needed ? Would love to see this feature implemented <3 |
Hey! Sure, still top of mind for me but I'm pretty lazy with fixing the conflicts, not a lot of time right now |
I've been trying to resolve the commits but this is a bit of a headache... For example, the new
has a side effect with |
@StanGirard how should we proceed about getting this merged? I fixed the issues, but now there is again more conflicts |
We will help you :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What a PR ! @raoufchebri & @Noezor thanks a lot !!!!
There's more to come though! 😊 |
…roviders (#646) * add sqlalchemy models * add neon settings * add insert brain * abstract supabase from Brain class * abstract supabase from Brain class * abstract supabase from /models * update Database to Repository * update neon_tables to pg_tables * update chat, api-key and message * update vector class * update settings * update env vars for test * Update backend-tests.yml * fix test * fix fetch_user_requests_count() * fix fetch_user_requests_count() * fix increment_user_request_count * fix increment_user_request_count * fix asset upload_response message * fix pyright * fix brain_subscription * fix brain_subscription * fix brain_subscription * fix get user request stat * update create_brain_user * add delete brain vector and user * add delete brain vector and user * correctly call function --------- Co-authored-by: Noé Pion <noe.pion@onfido.com> Co-authored-by: raoufchebri <raouf@chebri.com> Co-authored-by: Stan Girard <girard.stanislas@gmail.com>
Original goal of this MR was to make the repo able to store data in multiple datasources, not only supabase, and implement neon.
Given how big the MR already is, we reduced the scope to introducing a repository pattern behind which we can access one of the implemented databases.
Another MR will follow to add sqlalchemy for other sql-compatible systems - starting with neon.
For supabase, we decided to keep the API because this is the prefered way to access the datasource there.