probléme avec serialize

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : probléme avec serialize

par titerm » 17 sept. 2007, 12:21

Tout dépend du contexte évidement, mais si jamais l'objet stocké évolu (que ce soit en milieu de projet ou 3 ans après parce qu'on a toujours de nouveaux besoins) ça devient une véritable galère à remettre à jour dans la base...
@ryle: Dans mon cas, le fait que la donnée soit sérialise donne beaucoup de souplesse et évite d'avoir a faire des MAJ BDD. Mais je n'ai peut être pas éte assez précis dans ma façon de faire. Je n'exploite pas directement l'objet désérialise mais je passe par une méthode de l'objet qui reconstruit elle même l'objet. Je travail donc toujours avec la dernière version de l'objet même si j'ai des propriétés qui ne sont pas renseigné, ce sont les accesseur qui géreront le défaut.
class objLien {
	public $href;
	public $label;
	public $target;
	
	public function get() {return serialize($this);}
	public function set($v) {
		$tmp = @unserialize($v);
		$list = array_keys(get_object_vars($this));
		foreach($list as $attr) {
			$this->$attr = empty($tmp->$attr) ?  null : $tmp->$attr;		
		}
	}
	public function __set($attr, $value) {$this->$attr = $value;}
}


class objLien2 {
	public $href;
	public $label;
	public $target;
	public $accessKey;
	
	public function get() {return serialize($this);}
	public function set($v) {
		$tmp = @unserialize($v);
		$list = array_keys(get_object_vars($this));
		foreach($list as $attr) {
			$this->$attr = empty($tmp->$attr) ?  null : $tmp->$attr;
		}
	}
	public function __set($attr, $value) {$this->$attr = $value;}
}

$foo = new objLien();
$foo->href = 'http://www.google.com';
$foo->label = 'Google';
$foo->target = '__parent';

$r = $foo->get();

$foo2 = new objLien2();
$foo2->set($r);
var_dump($foo2);

Imagine que tu gères un objet lien (avec url, label, target, les events etc...). Tu stocks la version serialisé dans la base. ObjLien

Plus tard, tu veux ajouter la navigation clavier et donc ajouter l'attribut ACCESSKEY. Tu met a jours l'object (ObjLien2). A partir de maintenant, tu peux gérer cette propriété. Soit elle n'est pas renseigné dans les ancien objets auquel cas, c'est le webmaster qui devra la renseigner, soit elle l'est et tu peux la traiter.

Plus tard encore, tu passes au HTML strict. Donc l'attribut target devient interdit. Tu peux le supprimer de la classe ou simplement l'ignorer dans les méthodes de la class, dans le toHTML() par exemple, ne en faire plus le rendu.

C'est juste un exemple simplifié pour donner une idée.

par Calimero » 17 sept. 2007, 11:07

@titerm : tout pareil...
@zeus : oui c'est bien ça. serialize() dans ce cas est un couteau suisse bien appréciable.
@Ryle : C'est un débat intéressant oui. Je pense qu'on pourrait l'élargir à "Peut-on produire autre chose que du quick and dirty avec serialize() ?"

Et pour ce qui est du contexte, c'est pouvoir de décision/conseil/réflexion pas loin de zéro, et horizon de développement : très court terme :-) La question de l'évolutivité à 3 ans est nulle et non avenue dans ce cas. Mais en effet, ça condamne tout du coup, ce n'est pas un choix à faire à la légère.

par zeus » 17 sept. 2007, 10:57

Là où je suis 100% d'accord, c'est que quand on te donne un cahier des charges et te disant +/- clairement "ferme ta bouche, c'est déjà décidé", tu peux en venir à faire des choses qui ne te plaisent pas mais sans pouvoir donner ton avis ;)

par Ryle » 17 sept. 2007, 10:51

Beuh justement, c'était un débat intéressant et il méritait bien un sujet pour lui tout seul m'enfin bon, puisqu'on en est à pourrir celui-ci.... ;)

Quant à sérialiser un objet en base, j'en suis pas fan non plus. Tout dépend du contexte évidement, mais si jamais l'objet stocké évolu (que ce soit en milieu de projet ou 3 ans après parce qu'on a toujours de nouveaux besoins) ça devient une véritable galère à remettre à jour dans la base... :?

par titerm » 17 sept. 2007, 10:49

Oui, sauf que dans mon cas, les clients sont des clients interne. Et les conseilles, c'est même pas la peine d'y penser (j'ai essayer une fois, je m'en remet doucement). Sauf si c'est un avis technique ou une impossibilité technique, le reste, il me diront que c'est pas mon domaine. Idem pour la BDD et idem pour la gestion des serveurs (physique ou apache). Moi, la seule chose sur laquelle je peux faire qq chose, c'est les sources. Je n'ai pas accès ni aux serveurs d'intégration, ni aux serveurs de prod. C'est très cloisonné et chaque service est jaloux de ses prérogatives. Y a même des moments ou on a l'impression de bosser dans des boites différentes. Enfin, ceci mis a part, ça reste très intéressant techniquement.

par Calimero » 17 sept. 2007, 10:30

Je comprend que vous ayez cette vision des choses.

Je fait parti d'une boite où nous nous permettons de conseiller très fortement le client.
Je travaille sur le plus gros diffuseur de pub français et je peut te dire que quand on conseille au client ne nous donner plus de temps pour ne pas rendre bancal la diffusion, il nous écoute.

Toute la journée, je travaille sur comment modifier le schéma de base de données sans mettre la diffusion HS pendant 4h ... et on se démerde pas mal ...

Je me tiens toujours au maximum à la vision théorique des choses, ce qui, jusqu'a maintenant, correspond à la vision des choses de mon boss et nous permet de ne jamais se diriger droit dans un mur.

Effectivement, j'utilise aussi certains passe-droit pour ne pas avoir à passer 6h là où 10mn suffisent.
Toujours est-il que sur une base de données, je ne me le suis jamais permis, et je n'ai jamais démonté une base, même une base qui collecte plusieurs milliards de hits par jours
On n'est sûrement pas si différents ;-) . C'est juste une question de marge de manoeuvre.

D'un boulot à l'autre, les besoins ne sont pas les mêmes, la réflexion en amont et les interlocuteurs non plus, et ça peut tout changer. Là où je suis en ce moment j'aurai plutôt tendance à choisir l'architecture la plus élégante et la plus maintenable (priorité aux données). Dans ce job dont je parlais plus haut, il s'agissait vraiment d'aller vite et de produire du jetable. Il y a un monde entre les deux :D

par zeus » 17 sept. 2007, 10:24

Je comprend que vous ayez cette vision des choses.

Je fait parti d'une boite où nous nous permettons de conseiller très fortement le client.
Je travaille sur le plus gros diffuseur de pub français et je peut te dire que quand on conseille au client ne nous donner plus de temps pour ne pas rendre bancal la diffusion, il nous écoute.

Toute la journée, je travaille sur comment modifier le schéma de base de données sans mettre la diffusion HS pendant 4h ... et on se démerde pas mal ...

Je me tiens toujours au maximum à la vision théorique des choses, ce qui, jusqu'a maintenant, correspond à la vision des choses de mon boss et nous permet de ne jamais se diriger droit dans un mur.

Effectivement, j'utilise aussi certains passe-droit pour ne pas avoir à passer 6h là où 10mn suffisent.
Toujours est-il que sur une base de données, je ne me le suis jamais permis, et je n'ai jamais démonté une base, même une base qui collecte plusieurs milliards de hits par jours

par titerm » 17 sept. 2007, 10:11

Ce que je veux dire c'est que ce sont des données administrés par le webmaster. Elle n'ont une durée de vie qu'un temps extrêmement court. Par exemple, ca va etre une image et tout ce qui la compose (le alt, le onclick etc...), ou dans le cas d'un lien ce sera l'url, le label, les events, etc...).

Maintenant comme tu le dis, personne ne convaincra l'autre. Pour une raison simple, c'est que tu ne voie que la méthode et que tu ne voie pas le contexte. Je suis dans une grosse boite, une modif de schémas, c'est une galère a gérer, trop de monde impliqué, du coup, ca prend enormément de temps, d'énergie, etc... Le marketing change d'avis tous le temps et du coup le contenu aussi. Cette solution est pour nous un moyen simple de pouvoir répondre rapidement a des demandes ésotérique sans remettre en cause en permanence l'existant.

par Calimero » 17 sept. 2007, 10:07

De plus, l'indépendance de la donnée face à la présentation me semble extremement importante ...
Selon ma vision de la base de données, je n'ai rien à modifier en base de données si je change la présentation de ces données ...

Mais bon, je pense que personne n'arrivera à convaincre l'autre ;)
En effet zeus, tu défends une vision théorique idéale qui peut parfois être source d'un gros casse-tête, en particulier quand tu te retrouves avec un nouveau besoin en milieu de projet, que ta base est déjà faite et que tu ne souhaites pas trop la retoucher.

Je me suis retrouvé devant le même choix que titerm et j'ai dû, à contrecoeur, opter comme lui. Après étude, le projet sur lequel je travaillais (et surtout l'agrégat de données en question) n'avait pas vocation à être attaqué dans un autre langage et de plus l'agrégat n'était que très peu factorisable et censé être évolutif. Un genre de fourre-tout, quoi. Stocker des structures sérialisées était une solution à la fois souple et rapide à mettre en oeuvre plutôt qu'une modif lourde de la base de données et des procédures métier pour la manipuler qui allaient avec.

Conclusion : les specs qui changent en milieu ou en fin de projet, c'est très très mal :D

par zeus » 17 sept. 2007, 09:44

euh ... je fait évoluer les interfaces de tous les projets sur lesquels j'interviens et je ne change pas le modèle de données à chaque fois ...

De plus, l'indépendance de la donnée face à la présentation me semble extremement importante ...
Selon ma vision de la base de données, je n'ai rien à modifier en base de données si je change la présentation de ces données ...

Mais bon, je pense que personne n'arrivera à convaincre l'autre ;)

par titerm » 17 sept. 2007, 08:20

L'algorithme serialize de php est connu et il existe des unserialize dans d'autre langage. J'en ai même codé un en javascript a l'époque ou JSON n'était qu'une extension PECL non intégré au core PHP.
C'est plutôt trivial à faire.
J'aurai pu utiliser JSON mais json_encode ne vois pas pas les propriété privé et protected.
Il serait aussi possible faire un proxy de conversion JSON/Serialize mais encore une fois, je n'en vois pas l'intérêt. Les données qui sont stockées en base sont les données qui font vivre le site et n'ont pas vocation à être conserver ad vitam eternam. Le jour où on changera de langage, il y aura forcement une nouvelle charte graphique avec et des nouvelles maquettes. Et donc de nouvelles données.

par zeus » 16 sept. 2007, 22:39

Une image stockée dans une base de données à un sens puisqu'elle est en relation avec la données.
Cette image est stockée en binaire et tout langage est capable de lire du binaire pour reconstruire l'image originelle, soit directement, soit via des couches additionnelles.

Alors que sérializer un objet d'un langage en base de données, c'est imposer la lecture de la base de données avec le même langage. Je doute fort que PHP et Java sérialize leurs objets de la même manière
Comme je te le disais précédemment, dans 80% des projets, on ne change pas le langage ... mais il reste 20% ...

par titerm » 16 sept. 2007, 21:15

Zeus, quand on stock une image dans un blob, on ne stock pas l'éditeur avec. A la relecture, on est censé soit savoir l'afficher, soit savoir la modifier.
Et quand je stock une version sérializé d'un objet, c'est pareil, je suis censé avoir la classe dont il est issu. Mais rien n'empêche aller un poil plus loin et de stocker le source de la classe au sein d'un meta objet.
Mais je trouve cela superflu. Le jours où je n'ai plus la classe pour exploiter les données, cela signifie aussi que le site est HS...

par zeus » 16 sept. 2007, 10:50

Pardon Mr Ryle, mais j'ai l'impression que l'auteur n'est toujours pas revenu ...

Sinon, pour répondre à titerm, je suis partisan du fait qu'une structure de données qui représente les données qu'elle contient permet toute modification sur ces données ...
Mais bon ... j'espère pour toi que tu ne te retrouveras jamais dans un cas où tu te diras que j'avais raison ;)

par titerm » 16 sept. 2007, 09:59

Ryle: La question de départ à eu sa réponse mais a soulevée une digression vers le sérialize qui n'est pas forcement inintéressante.

Dans mon cas, l'intérêt est de pouvoir stocker un agrégat de données représentant une seule donnée. L'agrégat étant évolutif sans pour autant avoir d'impact sur le schéma de la base. Les évolutions de schemas étant toujours assez complexe en prod surtout quand on est sur du 24/24 et que l'on veux pouvoir gérer le retour arrière sur tel ou tel évolution.

La contrainte est qu'il ne faut pas avoir besoin de faire des requêtes sql sur cet objet. Sur un objet complexe, cela limite le nombre de colonne aussi qui peut devenir pénible a gérer/lire si une table doit gérer plusieurs objets complexe.