Je pense que tu peux le clore.
Mais si tu veux une bizzarerie des sessions... ( Mais est-ce un problème des sessions ? )
Va dans l'admin, n'importe où, gérer par exemple et fait un refresh...
8-)
Hors ligne
VDigital a écrit:
Je pense que tu peux le clore.
Non je ne pense pas. Le bug y est mais je n'arrive pas à comprendre comment le reproduire de manière sûre. Je l'ai quelque fois mais pas tout le temps.
J'ai fini par trouver un moyen de le reproduire facilement. J'ouvre deu onglets: un sur admin, un sur galerie. Dans la partie admin je mets sur le panier. Dans la partie galerie j'ajoute des photos. Je clique une fois pour ajouter la photo dans le panier. Je raffraichie la page dans la partie admin et j'essaie d'ajouter de nouveau la photo dans la galerie. J'ai alors le bug.
Je l'ai finalement corrigé. C'est Radu qui l'avait introduit involontairement en corrigeant le code que j'avais écrit. Il avait voulu supprimer une requête en utilisant mysql_affected_rows. Bonne idée mais il ne faut faire l'insertion que si cette fonction renvoie -1!
Dernière modification par nicolas (2006-04-14 11:55:10)
Hors ligne
nicolas a écrit:
J'ai corrigé et amélioré. Pour moi c'est correct et pour vous ?
Tel que c'est maintenant sous svn tu porras avoir une Erreur MySql a la fin de ta page (duplicate key) si t'as un client et un serveur tres rapides et tu passes sur 2 pages dans la meme seconde. C'est la raison de mon test supplementaire.
Et en fait mysql_affected_rows va jamais retourner -1 car dans ce cas pwg_query appelerait la fonction die bien avant.
Hors ligne
rvelices a écrit:
nicolas a écrit:
J'ai corrigé et amélioré. Pour moi c'est correct et pour vous ?
Tel que c'est maintenant sous svn tu porras avoir une Erreur MySql a la fin de ta page (duplicate key) si t'as un client et un serveur tres rapides et tu passes sur 2 pages dans la meme seconde. C'est la raison de mon test supplementaire.
dans ce cas il faut changer le type du champ et passer de datetime à timestamp (ou int(11)). La probabilité de faire une requête dans le même timestamp est alors nulle.
Je reste persuadé que ta méthode n'est pas la bonne.
Hors ligne
nicolas a écrit:
Je reste persuadé que ta méthode n'est pas la bonne.
Peut etre, mais les requetes sont optimisees et il n'y a aucune erreur. Si tu trouves un autre moyen tres bien. Sinon on peut toujours revenir a ta version initiale, cad nombre de requetes non optimise, mais correct.
Hors ligne
rvelices a écrit:
nicolas a écrit:
Je reste persuadé que ta méthode n'est pas la bonne.
Peut etre, mais les requetes sont optimisees et il n'y a aucune erreur. Si tu trouves un autre moyen tres bien. Sinon on peut toujours revenir a ta version initiale, cad nombre de requetes non optimise, mais correct.
comme je disais on change le type du champ en int et en utilisant microtime() comme date d'expiration. Ce ne te convient pas ?
Hors ligne
nicolas a écrit:
comme je disais on change le type du champ en int et en utilisant microtime() comme date d'expiration. Ce ne te convient pas ?
C'est bon, mais il faudrait mettre plutot un BIGINT ou soustraire une grande valeur des secondes microtime() pour ne pas avoir un depassement.
Hors ligne
rvelices a écrit:
nicolas a écrit:
comme je disais on change le type du champ en int et en utilisant microtime() comme date d'expiration. Ce ne te convient pas ?
C'est bon, mais il faudrait mettre plutot un BIGINT ou soustraire une grande valeur des secondes microtime() pour ne pas avoir un depassement.
J'essaie de regarder ça dans la journée.
Hors ligne
rvelices a écrit:
OK. En fait si tu trouves trop complique le truc de microtime, on peut tout laisser comme c'est, mais pour la requete d'insertion on appele directement mysql_query a la place de pwg_query. Comme ca pas de message d'erreur.
On va y arriver! :-)
Hors ligne