herve_02 sur PhenixTweet

herve_02 @herve_02

1 mois

Ce qu'il manque : un shéma complet de la base de donnée (j'avais commencé un bout au tout début, je dois avoi qqpart un fichier .svg.
ET une doc avec tous les hooks et les ordres de passages et "objects" concernés. même le livre de j'avais acheté est plus une sorte de cookbook que de la documentation.
Maintenant les programmeurs on a tendance à dire qu'il suffit de lire le code, mais du coup le ticket d'entré est compliqué surtout avec les objets et les enfers des héritages (et des overrides par dessus le tout.
Et je ne parle pas de l'enfer des modules, chacun réécrivant ce qui lui plait.

herve_02 @herve_02

a répondu au Message de herve_02 il y a 1 mois (E)

oui dans la table le statut 32 (le mien) pass après le statut 2 (statut paiement accepté)
53351 | 0 | 22325 | 2 | 2026-09-29 15:52:59

53350 | 0 | 22325 | 32 | 2026-09-29 15:52:59 |

J'aurais tendance à suspecter une sorte de "cache" des instructions update mariadb qui "flush"(ent) à un moment et comme les 2 instructions arrivent "au même moment" (suivant la granularité de l'interface de "vidage" du cache

30 jours

a répondu au Message de herve_02 il y a 30 jours

Non, il passe AVANT (regardez les IDs)

herve_02 @herve_02

1 mois

a répondu au Message de herve_02 il y a 1 mois

ou alors il s'écrit __après__ (mais en même temps dans le cache à la même date_time ) MAIS le fait d'avoir un date_time en secondes plutôt qu'un timestamp en milliseconde(et donc les deux sont 'en même temps') fait que mariadb ne sait pas dans quel ordre le mettre et poufff pas de bol ???
Ou alors je délire... (ce qui est bien possible - faire de l'objet dans un monde deconnecté est un poil schizophrène.
Mais en même temps commande enregistrée (bien qu'au même date_time) est enregistré avant (logique)
je suis perdu.
Et c'est _tout le temps_ dans l'autre sens, .../...

herve_02 @herve_02

1 mois

a répondu au Message de herve_02 il y a 1 mois

et donc statistiquement impossible que ce soit du hasard dans l'ordre d'enregistrement.
On loupe un truc dans le mécanisme des hook.
Mais je suis un noob.(pour le moment). Disons un noob niveau 2.

30 jours

a répondu au Message de herve_02 il y a 30 jours

étant donné qu'on est dans le même process d'ajout de statut (qui s'empilent) ajoutez un sleep(1); (1 seconde) dans votre code avant de changer le statut pour être sûr que votre enregistrement se fera la seconde suivante.

(2) Afficher ce fil

herve_02 @herve_02

1 mois

a répondu au Message de herve_02 il y a 1 mois

Mais en même temps, je ne suis pas assez (pas du tout pour le moment) expert de phenix peut être qu'il y a une sorte de queue d'instructions (des objets, dans des objets, dans des objets, un truc entre genre sql et sql_slave) (il y a au moins 4 requêtes de recherche (elles même partagées en 3 ou 4 chemins de requêtes, ajax pas ajax,requete directe puis requête par pondération des mots - une sorte d'enfer Et la requête par ref (super intelligent ad-on eola) : produit, recherche, catégorie, fournisseurs) et peut être que lorsque les requêtes remontent dans les objets, il y a une race condition.

herve_02 @herve_02

1 mois

a répondu au Message de herve_02 il y a 1 mois

Peut être (c'est une figure de style) que je ne comprends pas la philosophie phenix/prestashop1.6
Et comme prestashop est un empilement de modifications/ajouts pendant presque 20 ans...
Il y a 2 fois la même requête pour chaque page chez moi si je trace le contoleur produit il "spits" 2 fois sur une page produit. (peut être ma faute) et le système de module, plutôt que de modifier les requêtes (la maniere "simple", mais overrride et donc diversion et donc perte des écolutions) écrit une requête supplémentaire. le curseur entre facilité de faire modules et performance.

(1) Afficher ce fil