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

Support for asyncpg #417

Open
davidolrik opened this issue Jul 9, 2021 · 2 comments
Open

Support for asyncpg #417

davidolrik opened this issue Jul 9, 2021 · 2 comments
Labels
Issue appropriate for: Occasional contributors 😉 This issue will be best tackled by people with a minimum of experience on the project Issue contains: Exploration & Design decisions 🧩 We don't know how this will be implemented yet Issue contains: Some documentation 📚 This issues involves writing some documentation Issue contains: Some Python 🐍 This issue involves writing some Python code Issue type: Feature ⭐️ Add a new feature that didn't exist before

Comments

@davidolrik
Copy link

Would it be feasible to add support for asyncpg? (Maybe even replace aiopg)

procrastinate is written specifically for running on postgres, and so is asyncpg, which is why it is extremely performant. asyncpg is way faster than aiopg, and it is even faster than golangs pgx.

Furthermore, it is supported by encode/databases which plays very well with FastAPI, SQLAlchemy Core and ormar.

@elemoine
Copy link
Contributor

elemoine commented Jul 9, 2021

Yes, we've considered it. We could start by adding support for asyncpg as opposed to replacing aiopg. PRs are very welcome!

@ewjoachim
Copy link
Member

ewjoachim commented Jul 11, 2021

One thing I see that might make things a bit more complicated is that the format for query parameters is different in aiopg (%(name)s) and asyncpg ($n).

That being said, I believe we should be able to automate the translation between the 2 formats:

In [3]: class Converter:
   ...:     def __init__(self):
   ...:         self.order = []
   ...:
   ...:     def __getitem__(self, key):
   ...:         self.order.append(key)
   ...:         return f"${len(self.order)}"
   ...:
   ...:     def convert_args(self, args):
   ...:         return tuple(args[e] for e in self.order)
   ...:

In [4]: c = Converter()

In [5]: s = "%(abc)s yay %(def)s" % c

In [6]: s
Out[6]: '$1 yay $2'

In [8]: c.convert_args({"def": "bar", "abc": "foo"})
Out[8]: ('foo', 'bar')

(This is just a POC code, we should be able to make something cleaner, but at least we can be reasonably sure that it's feasible)

@ewjoachim ewjoachim added Issue appropriate for: Occasional contributors 😉 This issue will be best tackled by people with a minimum of experience on the project Issue contains: Some documentation 📚 This issues involves writing some documentation Issue contains: Exploration & Design decisions 🧩 We don't know how this will be implemented yet Issue contains: Some Python 🐍 This issue involves writing some Python code Issue type: Feature ⭐️ Add a new feature that didn't exist before labels Sep 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue appropriate for: Occasional contributors 😉 This issue will be best tackled by people with a minimum of experience on the project Issue contains: Exploration & Design decisions 🧩 We don't know how this will be implemented yet Issue contains: Some documentation 📚 This issues involves writing some documentation Issue contains: Some Python 🐍 This issue involves writing some Python code Issue type: Feature ⭐️ Add a new feature that didn't exist before
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants