Skip to content

Async interface? #7

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

Open
mike-5345 opened this issue Mar 4, 2025 · 3 comments
Open

Async interface? #7

mike-5345 opened this issue Mar 4, 2025 · 3 comments

Comments

@mike-5345
Copy link

Hello,

I am considering ODB for a project. I notice that it doesn't have an async interface. Are there any plans on adding one?

Thank you,
Mike

@boris-kolpackov
Copy link
Member

I don't think this will be easy, or even possible. So, no, no plans.

To elaborate, we already in some sense support async, or at least non-blocking, where the underlying database supports it. Specifically, if the database supports streaming query result, you can iterate over it as the results become available. There is no way to "peek" to see if the next row is available, but you can do some work between rows.

Another related functionality is bulk update/insert/delete that is supported by PostgreSQL, MSSQL, and Oracle. This allows you to perform the same operation on a large number of objects and underneath things will happen in parallel/interleaving.

Other than that, I believe we will quickly run into the API limitations of the underlying database client libraries.

@mike-5345
Copy link
Author

Thanks for the detailed response.

I understand it may beyond the scope of the project, but I think Postgres offers an any interface through PQsendQuery. Is that what you were referring to?

Anyways I'm not sure on the others. Thanks anyways. I may just write a database thread pool to approximate async.

@boris-kolpackov
Copy link
Member

I think Postgres offers an any interface through PQsendQuery

That's what we use for bulk INSERT/UPDATE/DELETE, though the async'ness is not exposed to the application but rather used internally to process a large number of statements.

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

No branches or pull requests

2 participants