MagicStack / MagicStack/asyncpg

Feature Request: Middleware

Ouverte
#152 3 commentaires 5 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

enhancement
Langage dominant
Python
Étoiles
8.1k
Forks
468
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

As discussed in #128, it might be a cool idea to have a "middleware" layer in asyncpg where people can register their own code to be ran pre or post query.

One usecase is asyncpgsa, which is a project to allow sqlalchemy objects to be passed to asyncpg connection methods. If there was a middleware layer, asyncpgsa could simply be a middleware that would run right before asyncpg prepared the query to convert the sqlalchemy object into a string. This would make asyncpgsa stupid simple, and just be a conversion layer, allowing it to get out of the way, and let asyncpg be the source of truth for everything else.

Another use case is metrics. My org is starting to track metrics per endpoint and per database query. If asyncpg had middleware support, we could simply inject a middleware that tracked the query and the time it took, and send that information into our metric platform. This could be done today by wrapping asyncpg and adding a method around it that tracks the metrics. It would be amazing if instead asyncpg could be used directly, and the middleware handles that portion for me.

Middlewares could potentially be "added" when the pool is created. (they can only exist on a pool maybe?)

Anyways, I am happy to try to implement this if you would like, but first wanted to get a general discussion going on the topic.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Lisez d’abord l’issue #128, puis examinez la création du pool et les méthodes de connexion afin de déterminer où les middlewares pre- et post-query pourraient être enregistrés et invoqués. Comparez les cas d’utilisation de la conversion d’asyncpgsa et des métriques, puis définissez l’API, la portée, l’ordre, le comportement async et les tests nécessaires avant l’implémentation.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
postgresql, python
Domaine
backend, databases
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.