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

upsert multi #110

Closed
feluelle opened this issue Jun 24, 2024 · 4 comments · Fixed by #119
Closed

upsert multi #110

feluelle opened this issue Jun 24, 2024 · 4 comments · Fixed by #119
Labels
enhancement New feature or request

Comments

@feluelle
Copy link
Contributor

feluelle commented Jun 24, 2024

Is your feature request related to a problem? Please describe.

If I currently want to upsert multiple records I would have to call upsert for each model which means a lot of overhead and unnecessary db calls. A Multi-upsert can also be done in just one query.

Describe the solution you'd like

I would like to have an upsert function that allows inserting or updating multiple models. It doesn't have to be in one query necessarily. We can also continue with the current strategy using get and create or update.

Describe alternatives you've considered

The current alternative (postgres specific) I am using is:

from sqlalchemy.dialects import postgresql

stmt = postgresql.insert(...).on_conflict_do_update(...)
await session.execute(statement=stmt, params=...)
@feluelle feluelle added the enhancement New feature or request label Jun 24, 2024
@JakNowy
Copy link
Contributor

JakNowy commented Jun 25, 2024

Postgresql solution looks best, but it makes it fail if other dbms is used.

Honestly I would opt for focusing on postgresql as the most popular dbms and making it as efficient as possible (I don't quite like the get and create approach as it costs additional call). That way we could efficiently cover bulk operations of all crud types. Igor mentioned that we might redesign some parts of the library and relase a breaking 1.x.x version, so that might be a good moment to get that transition.

For now I think we should stick to the get and create/update approach for consistency. If you need that done soon, feel more than welcome to open a PR. Otherwise I might cover that but I'm having a few other issues to be finished first.

@igorbenav your thoughts?

@igorbenav
Copy link
Owner

I think what we should aim for eventually is a db "engine" approach, falling back to this get and create when engine is not specified, identified or covered, I think that would justify a breaking version. Until we do something like this, I believe creating the fallback would be the way to go

@igorbenav
Copy link
Owner

Btw there's a lot that still needs to be done before we (as in me and @JakNowy) actually get to creating the db engine approach, so if you feel like you could do it (and need it done), @feluelle, we'd be more than happy.

@feluelle
Copy link
Contributor Author

feluelle commented Jul 4, 2024

Cool, will give it a try.

@feluelle feluelle mentioned this issue Jul 4, 2024
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants