Skip to content
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

Merged
merged 31 commits into from
Aug 1, 2023

Conversation

Noezor
Copy link
Contributor

@Noezor Noezor commented Jul 13, 2023

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.

@vercel
Copy link

vercel bot commented Jul 13, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Aug 1, 2023 5:51pm

@vercel
Copy link

vercel bot commented Jul 13, 2023

Someone is attempting to deploy a commit to the Quivr-app Team on Vercel.

A member of the Team first needs to authorize it.

@StanGirard
Copy link
Collaborator

Cant wait to see the end :)

@gozineb
Copy link
Contributor

gozineb commented Jul 19, 2023

@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.

@Noezor
Copy link
Contributor Author

Noezor commented Jul 19, 2023

Work has been moved to raoufchebri#1

The current solution is that we want to keep the supabase integration the way it is, but add Sqlalchemy for the others (including neon). We are keeping the supabase integration this way instead of using Sqlalchemy as supabase does not use connection pooling so using the API is the favored method.

Copy link
Contributor Author

@Noezor Noezor left a 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 ?

.execute()
)
return [item["brains"] for item in response.data]
return self.commons["db"].get_user_brains(user_id)
Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree 44c6a2a

Copy link
Contributor

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 !

Copy link
Contributor Author

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?

Copy link
Collaborator

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 ;)

commons["supabase"].table("chats").delete().match(
{"chat_id": chat_id}
).execute()
commons["db"].delete_chat
Copy link
Contributor

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 Noezor changed the title Draft: feat: add neon feat: Introduce repository pattern to prepare adding other database providers Jul 20, 2023
@StanGirard
Copy link
Collaborator

@Noezor @raoufchebri any update or help needed ? Would love to see this feature implemented <3

@Noezor
Copy link
Contributor Author

Noezor commented Jul 25, 2023

Hey! Sure, still top of mind for me but I'm pretty lazy with fixing the conflicts, not a lot of time right now
@raoufchebri ?

@Noezor
Copy link
Contributor Author

Noezor commented Jul 29, 2023

I've been trying to resolve the commits but this is a bit of a headache...

For example, the new

        commons = common_dependencies()
        response = (
            commons["supabase"]
            .table("brains_users")
            .insert(
                {
                    "brain_id": str(self.id),
                    "user_id": str(user_id),
                    "rights": rights,
                    "default_brain": default_brain,
                }
            )
            .execute()
        )
        response = self.commons["db"].create_brain(self.name)
        self.id = response.data[0]["brain_id"]
        return response.data

has a side effect with side.id = blah, which means that we now need to refactor harder what we did and it is not entirely trivial to resolve. Help appreciated @StanGirard

@Noezor
Copy link
Contributor Author

Noezor commented Aug 1, 2023

@StanGirard how should we proceed about getting this merged? I fixed the issues, but now there is again more conflicts

@StanGirard
Copy link
Collaborator

We will help you :)

Copy link
Collaborator

@StanGirard StanGirard left a 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 !!!!

@StanGirard StanGirard merged commit 303ba72 into QuivrHQ:main Aug 1, 2023
2 of 6 checks passed
@Noezor
Copy link
Contributor Author

Noezor commented Aug 1, 2023

What a PR ! @raoufchebri & @Noezor thanks a lot !!!!

There's more to come though! 😊

StanGirard added a commit that referenced this pull request Sep 12, 2023
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants