Development #19842
family: fournir un endpoint de récuperation des NameIDs liés aux familles et qui ont des factures à payer
0%
Description
Afin de permettre à lingo de connaître les comptes liés aux familles.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Serghei Mihai il y a plus de 6 ans
- Lié à Development #13122: lingo: systeme de notification en cas de facture à payer ajouté
Mis à jour par Serghei Mihai il y a plus de 6 ans
- Sujet changé de familly: fournir un endpoint de récuperation des NameIDs liés aux familles à family: fournir un endpoint de récuperation des NameIDs liés aux familles
Mis à jour par Thomas Noël il y a plus de 6 ans
- Sujet changé de family: fournir un endpoint de récuperation des NameIDs liés aux familles à family: fournir un endpoint de récuperation des NameIDs liés aux familles et qui ont des factures à payer
Pour être plus précis : c'est dans la régie que ça doit être visible, donc un endpoint lié au système de facturation.
On veut qu'il retourne la liste des NameID qui valent la peine d'être interrogés, c'est-à-dire qui ont des factures à payer. Il faut que cette réponse remonte en (beaucoup) moins de 30 secondes ; donc si la liste précise est impossible, renvoyer la liste des NameID liés.
Pour le connecteur famille générique où tout est en base, une liste précise doit être possible.
Sur le format, on peut prévoir de renvoyer la liste des factures (mais pas le PDF, trop de volume) afin que lingo puisse optimiser encore son traitement.
Juste la liste des uuid :
err: 0
data: [
{ 'uuid:' ... },
{ 'uuid:' ... }
]
Quand Passerelle peut renvoyer les infos des factures en attente (cas de apps/family/) :
err: 0
data: [
{ 'uuid:' ..., 'invoices': [{ ... }, ... ]},
{ 'uuid:' ..., 'invoices': [{ ... }, ... ]}
]
Mis à jour par Serghei Mihai il y a plus de 6 ans
- Fichier 0001-family-add-endpoint-returning-users-with-pending-inv.patch 0001-family-add-endpoint-returning-users-with-pending-inv.patch ajouté
- Patch proposed changé de Non à Oui
Avec tests basés sur les données Orléans.
Mis à jour par Thomas Noël il y a plus de 6 ans
Vu de loin, je pensais qu'on pouvait faire ça en une seule requête SQL, en partant des factures (prendre celles qui sont à payer et liée à une famille qui existe dans familylink). Parce que dans le code ici, on va lancer autant de requête SQL que de famille liée, c'est un peu bourrin.
Mis à jour par Serghei Mihai il y a plus de 6 ans
- Fichier 0001-family-add-endpoint-returning-users-with-pending-inv.patch 0001-family-add-endpoint-returning-users-with-pending-inv.patch ajouté
Tu as raison.
Mis à jour par Thomas Noël il y a plus de 6 ans
Je pense qu'on peut se passer de reparcourir et reconstruire un dico, en changeant le format de sortie en un truc plus logique : {'uuid1': {'invoices': ...}, 'uuid2': {'invoices': ...}, ...}
genre :
data = defaultdict(lambda: {'invoices': []})@
for invoice in Invoice.objects.filter(payment_date__isnull=True, family__resource=self, family__familylink__isnull=False):
name_id = invoice.family.familylink_set.get().name_id # oups, ça requête ça, non ?
data[name_id]['invoices'].append(format_invoice(i))
return data
mais invoice.family.familylink_set.get().name_id effectue une requête, pour chaque facture, non ? (je sais qu'en SQL toute les infos peuvent être obtenues d'un coup, mais je suis pas bien fort en ORM Django pour l'écrire)
Mis à jour par Serghei Mihai il y a plus de 6 ans
- Fichier 0001-family-add-endpoint-returning-users-with-pending-inv.patch 0001-family-add-endpoint-returning-users-with-pending-inv.patch ajouté
Tel quel la ligne:
invoice.family.familylink_set.get().name_id
fait 2 requetes: une pour retrouver la famille et l'autre le nameid lié.
En passant par un select_related('family') il n'y a plus de requete pour récuperer la famille.
Il reste quand même que ni select_related ni prefetch_related ne permettent pas de ne pas taper une requete pour retrouver le nameid.
Mis à jour par Thomas Noël il y a plus de 6 ans
Serghei Mihai a écrit :
Tel quel la ligne:
[...]
fait 2 requetes: une pour retrouver la famille et l'autre le nameid lié.En passant par un
select_related('family')il n'y a plus de requete pour récuperer la famille.
Il reste quand même que niselect_relatedniprefetch_relatedne permettent pas de ne pas taper une requete pour retrouver le nameid.
Ça m'étonne, parce qu'on est d'accord qu'en SQL c'est possible d'avoir tout d'un coup ? (et là, on va se taper une requête par facture, c'est dommage). Un select_related('family__familylink') ça passe pas, voire select_related('family__familylink__nameid') ?
Mis à jour par Serghei Mihai il y a plus de 6 ans
Thomas Noël a écrit :
Ça m'étonne, parce qu'on est d'accord qu'en SQL c'est possible d'avoir tout d'un coup ? (et là, on va se taper une requête par facture, c'est dommage). Un
select_related('family__familylink')ça passe pas, voireselect_related('family__familylink__nameid')?
Oui, sauf que select_related ne permet que les jointures avec les tables vers lesquelles il y a un foreign key. Or c'est FamilyLink qui a une clé vers Family.
Je vais me casser un peu la tête pour optimiser ça.
Mis à jour par Benjamin Dauvergne il y a plus de 6 ans
select_related() marche peut-être si c'est un OneToOneField mais là c'est une ForeignKey, donc prefetch_related() puis
name_id = i.family.familylink_set.all()[0]
(quand on utilise prefetch_related() la requête mise en cache est disponible via .all()).
Mis à jour par Serghei Mihai il y a plus de 6 ans
- Fichier 0001-family-add-endpoint-returning-users-with-pending-inv.patch 0001-family-add-endpoint-returning-users-with-pending-inv.patch ajouté
Merci Benj.
En effet avec ça il n'y a plus de "hit" à chaque récuperation d'un nameid.
Mis à jour par Serghei Mihai il y a plus de 6 ans
- Statut changé de Nouveau à Résolu (à déployer)
- Assigné à mis à Serghei Mihai
commit ac274430eab584cae71c3688f4757a8eb83baec4 (origin/master, origin/HEAD)
Author: Serghei Mihai <smihai@entrouvert.com>
Date: Fri Nov 10 15:11:59 2017 +0100
family: add endpoint returning users with pending invoices (#19842)
family: add endpoint returning users with pending invoices (#19842)