Discussion :

[asterisk user]

Bonjour à tous, merci d'excuser mes 'fautes de gout' de nouveau venu....


Mon pb:
j'ai un jeux de rows à partir d'une table mysql....
je fais defiler ceux ci en avant ou arriere....
ce jeu est reactualisé toutes les x secondes ou 'actions'....


COMMENT RETROUVER, après cette 'actualisation', la position en lecture, sachant que l'enregistrement courant (avant reactualisation) à peut être disparu, que d'autres ont aussi peut être ajoutés ou effacés suite à cette réactualisation ?

Exemple: une liste de messages, une position $i et la lecture de ce message.... BIEN, simple, mais si, après lecture, on reactualise le jeu....

même en ayant noté quelque part (une $variable) une clé 'de réference' (exemple le N° du message, donc tout nouveau message vient avec un N° superieur au dernier en date et la suppression d'un message ne change pas les N° 'absolu', bien que changeant les indices dans le nouveau jeu


Je n'arrive pas à trouver une solution 'élégante' par les tableaux (je n'ai que Nouveau N° > N° de lecture, aucun indice 'à priori' dans le nouveau tableau)

Bien sur, une relance de requete sur mysql avec un select etc..... limit 1 est possible, mais GENANT dans la mesure ou il faut relancer une requete apres chaque message..... alors qu'un tableau permettrait de 'temporiser'.... donc diminuer le nombre de requees....
(j'ajoute que le cache de requete mysql est ici marginal, puisque le jeu change donc, cache viré (helas, sinon facile)


Bon, suis pas sur d'avoir ete explicite.... mais merci de toute suggestion

concret:
jeu initial de messages 100, 101, 103, 104, 105, 106, 107, 108

je suis en lecture de 103.... je quitte, il y a une réactualisation.... comment positionner le pointeur en lecture sur le message 'suivant' N° > à 103.... qui peut être 109 si 104 à 108 ont été effacés et 109 ajouté....
103 ayant peut etre lui meme disparu...
EN EVITANT SI POSSIBLE LA SOLUTION 1 par 1 du select.... limit 1....


data seek ? mais quel indice ?
creer un tableau avec 2 requetes mysqlI multiquery, ou 1 requete avec un 'filtre' <103, > 103 et on push le second jeu sur le premier , connaissant le nombre de rows du 1 avec count.... lourd, non ?
etc etc etc etc etc


C'est sans doute basique et stupide de ma part, et c'est une contingence exterieure....

Merci encore de toute solution ou direction, j'espere, malgré l'heure ne pas etre incomprehensible....

Bonne journée.....

[Bidouille]

PHP s'exécute côté serveur. Si tu veux agir sur l'affichage et donc côté client, il faut te servir du HTML.
Regarde du côté des ancres.

[Mr N.]

A mon avis pose ta question chez les pros de MySQL, i.e. sur le forum ad-hoc... C'est bien trop complexe pour moi

[asterisk user]

Bonjour et merci....


Non , non, ce ne doit pas etre tres complexe:
- faire une requete SELECT * etc etc (on a tout!)
- par contre après:
un SELECT count_row etc etc cf parametres de la doc mysql ..... where < Dernier N° => on a un l'indice de l'enregistrement dans le nouveau jeu
(ok, avec -1 si on commence à 0, bien sur)

donc, on peut faire un data seek sur cet indice.....
A PRIORI: une soultion correcte (mysqli possible), car on a un jeu complet et la bonne position de départ

MAIS EST CE PLUS RAPIDE (puisqu'ici tout se passe sur mysql) que le
SELECT * machin
suivi d'une analyse du tableau en php ? ( ex: foreach N° < N°départ, $n -> $n++ pour retrouver ce fameux indice de départ) ?

PHP est plus rapide dans l'analyse de tableau, pas de pb....
MAIS un bon tri sur une table mysql, avec index est 'bien'.....


ET PAR AILLEURS, IL N'Y A PAS PLUS BASIQUE COE POINTEURS ? (désolé de mon incompétence)


Bonne journée

[Mr N.]

Quel idée aussi d'utiliser des trucs compliqués

Essayons par un autre côté, quel est ton besoin fonctionnel ? Parce que bon utilisé des "pointeurs" comme tu le fais c'est assez louche...