Hello!
Petite question suite à un comportement bizarre du code: Comment stocker un objet en bdd et le récupérer sur la page plus loin?

l'idée étant:
le joueur se connecte, choisi le perso à activer... hop, activation, génération de l'objet 'perso' => stockage dans un champ 'objet' de la bdd.
(Objet = "serialize($p)" )
Que je peux récupérer plus loin, pour une donnée quelconque (combat, compétence, jet opposition, etc...)

Page d'inventaire:
1)Select Objet from perso Where ID=*id_perso*
2)j'inclus ma déclaration de classe
3) je le remet en place avec
$p=unserialize($p["Objet"]);

et non, ca marche pas...
Y a des trucs à faire gaffe? c'est pas la bonne méthode? enfin, bref: qu'est-ce qui pourrait faire que ca déconne? (sachant que ca marchait pendant les phases de tests)
un addslashes(serialize($objet)) est-il utile à l'enregistrement?

Tu pourais pas plutot mettre le code complet STP ?

As tu bien instancié ta classe en retour ?

Voir : http://fr.php.net/manual/fr/language.oop...zation.php

Quelle est la chaîne rendue par mysql ?
As tu échappé les guillemets ?

arf...
rien de tout ca, en fait, mais merci!

L'erreur débile... de mauvaise interprétation
A l'activation: méthode construct d'un objet...

Dans l'inventaire, je remet mon objet à jour partiellement, via une méthode de l'objet (appelée aussi par le construct). La méthode en appelle une autre (Maj magie), qui en appelle une autre (maj_caracs), etc...
Sauf que la dernière méthode, je l'ai tjs pas mise en fonction... donc, partie intégrante du construct... donc pas appellée si je demande juste une mise à jour...

En résumé, mon objet est bien sauvegardé, et bien mis à jour... y a juste que la dernière partie n'est pas finie, et que c'est ca qui bloquait (alors que je pensais qu'il ne me sauvegardait pas mon objet mis à jour... ce qui se fait, au final )

je corrige ce point, et je vois si c'est bien ca...
Je met pas encore le tag [Resolu] car un autre truc me turlupine... vais vérifier un truc avant de cloturer le sujet.

Bon, c'était bien ca ...
Honte sur moi.

Première erreur : mise à jour incomplète de l'objet perso. (corrigé)
Deuxième errzeur, sur une autre page, de débuggage: mauvaise méthode appelée => erreurs.

Résolu, donc

question certainement très bête

Quel intérêt de stocker toutes les propriétés dans un seul champ de la BDD et pas dans autant de champs qu'il y a de propriétés ?

je suis pas du tout dans une question polémique / péjorative, mais j'aimerai juste comprendre cette démarche que je n'applique pas perso ?

données volatiles...
a chaque changement d'équipement, chaque sort, chaque environnement, les caracs du perso changent...

Je stocke donc les valeurs qui ne changent pas, et je recalcule à chaque session de jeu ce qui en découle... ce qui est plutot lourd. (une dizaine de requetes + traitement)
Donc, je crée mon perso une bonne fois, à l'activation... et je stocke ce résultat.
Ensuite, a chaque page du jeu, j'ai une seule requete à faire pour récupérer un perso complet, et à jour.
Au final, c'est une économie processeur pour une perte minime de place.

A la déconnection, je vide le champ. (et ceux qui se déconnectent pas, ben... faut que je trouve un malus... a traiter pendant le chron nocturne sur les perso dont le champ n'est pas NULL )

L'(avenir me dira si je vois juste ou pas

oki

n'hésite pas à partager la dessus

pour l'instant je fais du "beau" modèle qu on apprend à l'école des théories basiques mais je n'ai aucune visibilité sur l'optimisation que l'on pourrait faire pour de telles transactions

bah, moi pareil
mon site, c'est mon TFE, après tout

Sauf que bon, optimiser, c'est tjs bien d'y penser avant, pendant, et après
tout en restant un peu cohérent...
C'est jamais que la 3e fois que je reprends mon système d 'inventaire (mais bon, c'est aussi la 3e version/orientation du site... a chaque but, ses nécessités. Ce qui est bon pour l'un n'est pas forcément le meilleur pour un autre.)

Waaaa... j'arrive a pondre de belles phrases,parfois, quand meme
Bon, la noter pour le TFE...