OgSpy 3.1.2 et suppression de planètes

Démarré par roms0406, 25 Décembre 2012, 15:41:18

« précédent - suivant »

roms0406

Bonjour,

Je viens de faire la mise à jour, content de ne plus avoir le bug lors de la suppression d'une planète je décide de tout remettre à zéro et là lors de la suppression d'une planète :

Database MySQL Error
ErrNo:1062: Duplicate entry '3-101' for key 'PRIMARY'
Query:
update ogspy_user_building set planet_id = 101 where planet_id = 110


??....

DarkNoon

Le Bug vient de la version précédente. Donc si tu utilises des données qui ont été créé avec une ancienne version d'OGSpy tu peux retomber dans l'erreur.
Héberger votre OGSpy : Hébergement

DarkNoon

Sinon la mise à jour s'est bien passée ? Es tu passé par autoupdate ou par par une mise à jour classique ?
Héberger votre OGSpy : Hébergement

roms0406

J'ai essayé de supprimer toutes les planètes et lunes pour faire le ménage, mais j'ai l'erreur à chaque fois ...

Sinon j'ai voulu passer par l'autoupdate mais je n'ai pas pu, OGSPY me dit que je n'ai pas les droits nécessaire pour faire la mise à jour (compte admin pourtant), donc j'ai fait une mise à jour manuelle

PS : Comment supprimer les données "planètes" d'un joueur, afin de ne pas reproduire le bug ??

DarkNoon

Il faut le faire via phpmyadmin.

Tu vas dans la table ogspy_users et tu repères l'id de ton utilisateur.

Après dans ogspy_building tu vires toutes les lignes qui ont pour user id celui que tu as relevé dans la table des utilisateurs.
Héberger votre OGSpy : Hébergement

DarkNoon

Sinon ta planète est bien effacée mais tu prends le message d'erreur à chaque fois :P
Héberger votre OGSpy : Hébergement

DarkNoon

Le problème a été identifié. Va falloir que l'on se plonge dans la bête pour le corriger ^^


Suivi ici : [size=78%]https://bitbucket.org/ogsteam/ogspy/issue/4/conflit-de-cl-primaire-lors-de-la-r[/size]


(Vous pouvez vous abonnez à l'ano pour avoir un mail lorsque cela sera corrigé ;-)
Héberger votre OGSpy : Hébergement

roms0406

Bonne nouvelle ça !!

Merci et Bonne Année ;)

iguypouf


machine

ben en fait c un peu ca le correctifs, malheureusement, ton post est passé a la trappe :s

le correctif sera present dans la prochaine version d ogspy

Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/

Superbox

Le problème ici, c'est que la clé primaire (player_id, planet_id => en l'occurrence ici, une partie de la cle, planet_id) sert aussi pour l'ordre des planètes et l'affichage à l'écran (planet-_id = 100, puis 101, 102, ...)
Or, modèle et vue doivent être absolument séparés.
Lier le numéro de la clé primaire à un ordre d'affichage strict dans la vue est une aberration !

Au pire on peut lister les éléments par l'ordre de leur clé primaire, c'est tout.
Mais l'ordonnancement des planètes doit se faire uniquement dans la vue (à l'affichage), et on ne doit en rien altérer le modèle (surtout pas les clé primaires !)
Cependant, on peut rajouter un champ (qui lui, ne fait pas partie de la clé primaire) pour sauvegarder le dernier ordonnancement choisi !

Vous pouvez retourner le problème dans tout les sens, ça sera toujours le bordel

Donc, une solution que je propose :
La clé primaire (player_id, planet_id) devient -> planet_id (auto_increment...ou alors l'id de la planète que l'on récupère dans Ogame)
Player_id devient une clé étrangère vers la table ogspy_user (mais ne doit plus faire partie de la clé primaire).

Ajout d'un champ (planet_pos par expl), et c'est dans celui-ci qu'il faudra y mettre la position de la planète et de sa lune associée telles qu'elles devront être ordonnancé dans la vue (afin que les lunes soient "en phase" avec leurs planètes, à l'affichage).
Note : on peut aussi se passer de ce champ, et lister les planètes/lunes par un ordre arbitraire, mais dans ce cas, il faut oublier la suppression/ré-ordonnancement manuel.

Ainsi, lors d'une suppression, on fait juste "-1" sur l'indice de toutes les planètes dont l'indice est > à l'indice supprimé, mais on ne touche pas aux clés primaires (parce qu'ici, c'est elles qui foutent le bordel lors des décalages, car on se retrouve avec des doublons et donc avec des conflits de clé).
Lors d'un ajout, on fait un +1 sur les indices.
Et si on veut inverser l'ordonnancement de deux planètes, on échange les indice.

Mais en aucun cas nous ne devons toucher aux clés primaires ! C'est une source d'embrouille (et je reste poli)^^

De plus, même s'il y a un problème sur l'incrémentation / décrémentation de ces indices, ça ne générera pas d'erreur sql. Au pire, la planète ne s'affichera pas (après, cela dépend comment est faite la fonction d'affichage...si elle se contente d'afficher en lisant bêtement l'indice, oui, sinon elle affichera deux planètes avec le même indice dans un ordre arbitraire : l'ordre de récupération)

machine

#11
ola,

j ai attentivement tout lu ton post

je pense que tu as raison sur tous les points ...


par contre petite question :

ca va impacter la vue espace perso ( eventuellement / stat simu )
au niveau xtense ca demande bcp de modif ?? ?

( parce que actuellement avec le correctif ca fonctionne, l implication et le dev en v5 n est elle pas prioritaire sur l optimisation de la v3 ? )


Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/

iguypouf

Dans ce cas, il y a encore bien plus simple :

Au lieu de faire un planet_id auto-increment, vous faites un planet_id qui recevra... le planet_id du jeu. Ainsi, les coordonnées d'une colo pourront être mises à jour suite à un déménagement sans devoir passer par l'espace perso.

Le second champ gèrera l'ordonnancement, mais... C'est tout :)

Superbox

Citation de: iguypouf le 10 Janvier 2013, 10:40:23
Dans ce cas, il y a encore bien plus simple :

Au lieu de faire un planet_id auto-increment, vous faites un planet_id qui recevra... le planet_id du jeu. Ainsi, les coordonnées d'une colo pourront être mises à jour suite à un déménagement sans devoir passer par l'espace perso.

Le second champ gèrera l'ordonnancement, mais... C'est tout :)

Ouaip, c'est ce que je disais aussi (dans une petite parenthèse xD)
Pour Xtense, il devrait y avoir des modifs (puisque la table change), mais après la maintenance/correction sera beaucoup plus aisée, et ça pourra même être réutilisé en tout ou partie pour la v5

Masterground

Citation de: darknoon le 25 Décembre 2012, 19:59:27
Il faut le faire via phpmyadmin.

Tu vas dans la table ogspy_users et tu repères l'id de ton utilisateur.

Après dans ogspy_building tu vires toutes les lignes qui ont pour user id celui que tu as relevé dans la table des utilisateurs.

Darknoon, j'ai un membre qui a le même problème

Citationdans le mod prod je peux pas modifier les position/temparture du ma 12e colo
[16:31:37] vins-Mr K: pareil dans l'espace perso
[16:31:47] vins-Mr K: "Une incohérence a été trouvée dans votre espace personnel
En rapport avec le nombre de vos planetes"

dans le journal OGSpy
Erreur critique mysql - Req : update ogspy_user_building set planet_id = 112 where planet_id = 115 - Erreur n°1062 Duplicate entry '6-112' for key 'PRIMARY'

Comme tu le sais je suis sur le serveur host.darkcity.fr et donc je n'ai pas accès à phpmyadmin
Comment puis-je résoudre ce problème temporairement en attendent un éventuel correctif?