[PHP 5.2] Restitution d'objet grâce aux sessions

[Shikiryu]

Bonjour,

Je me pose une question pour un de mes futurs projets perso.

En effet, j'ai prévu d'enregistrer un objet en session afin de pouvoir restaurer le même objet de page en page.

Au départ, j'avais trouvé une idée sur le net : dé/sérialiser l'objet en session à chaque fin et début de requête.

Exemple :

Code :

1
2
3
4
5
6
7
8
9
public static function saveCurrentObject(Object $objet){
     $_SESSION['objet'] = serialize($objet);
}
public static function restoreCurrentObject(){
     return isset($_SESSION['objet']) ? unserialize($_SESSION['objet']) : null;
}
public static function clearCurrentObject(){
     if(isset($_SESSION['objet'])) unset($_SESSION['objet']);
}

Mais vu la taille de mon objet, je trouve ça un peu... énorme à stocker. Je ne connais pas la mémoire utilisée pour la session mais j'imagine qu'elle n'est pas illimitée. J'ai donc modifié le code ainsi :

Code :

1
2
3
4
5
6
7
8
9
public static function saveCurrentObject(Object $objet){
     $_SESSION['objet'] = $objet->getId();
}
public static function restoreCurrentObject(){
     return isset($_SESSION['objet']) ? new Objet($_SESSION['objet']) : null;
}
public static function clearCurrentObject(){
     if(isset($_SESSION['objet'])) unset($_SESSION['objet']);
}

En gros, je garde uniquement les éléments servant à construire l'objet et le reconstruit à chaque requête après.

Je n'utilise pas les exemples ci-dessus tels quels, ils servent uniquement... d'exemples pour illustrer mon raisonnement.

Laquelle des solutions vous parait la moins gourmande en ressources ? Laquelle est la plus rapide ?
Et surtout, y a-t-il une autre solution que je n'aurais pas trouvé sur le net et à laquelle je n'aurais pas pensé ? (Sachant que je suis en PHP 5.2.17)

[boo64]

ça pourrait t’intéresser si tu ne l'as pas déjà lu

http://www.devshed.com/c/a/PHP/The-S...ns-in-PHP-5/2/

edit: avec le lien php.net c'est mieux http://php.net/manual/fr/oop4.magic-functions.php

[Shikiryu]

Ah ! Oui effectivement, j'avais lu ça.

Le problème, c'est la récupération. Car je peux avoir plusieurs instances du même objets sur une page et je ne sais pas trop comment le gérer avec les méthodes magiques __sleep() et __wakeup()

Et apparemment, la page que tu donnes s'arrête avant cette explication

Si tu as d'autres exemples mieux expliqués, je suis preneur !

[boo64]

http://www.devshed.com/c/a/PHP/The-S...ns-in-PHP-5/3/

oui exactement du coup je pense que c'est bien la solution la plus approprié

[Shikiryu]

Le lien du manuel explique bien ce que ça fait et comment l'utiliser.
Au final, ça enregistre l'objet sérialisé dans un fichier... ça revient au même que ce que je fais. J'ai juste réinventé la roue ?

[boo64]

je préféré l'exemple de mon dernier lien

sinon oui c'est ce que tu fais donc en gros moi :
implementation du sleep/wakeup
et ensuite session_register() et session_unregister() pr les passer en session.

[Benjamin Delespierre]

Je ne connais pas la mémoire utilisée pour la session mais j'imagine qu'elle n'est pas illimitée

Sauf indication contraire, ça part sur fichier.

Laquelle des solutions vous parait la moins gourmande en ressources ? Laquelle est la plus rapide ?

Je dirai, ça va dépendre de la taille de tes objets et des ressources consommées par la construction. Donc il faut voir si l'unserialize va plus vite que le constructeur, ce que tu peux faire avec un petit coup de profiling.

Tu pourrais peut être gagner à définir une logique de persistance découplée, ce qui te permettrait de choisir au runtime quelle stratégie adopter en fonction des objets à sérialiser (DB, Memcached, Redis, $_SESSION ou autre).

Juste une question:

Code :

public static function saveCurrentObject(Object $objet){

Je ne comprends pas du tout ce prototype.

[Shikiryu]

Envoyé par boo64

implementation du sleep/wakeup
et ensuite session_register() et session_unregister() pr les passer en session.

J'ai bien lu des tutoriaux et de la doc sur __sleep() et __wakeup().
Ils servent principalement à "nettoyer" l'objet ou à activer des méthodes avant de "l'éteindre" et de le "rallumer". Or, je ne pense pas en avoir besoin (pour l'instant) dans le cas présent.
Par ailleurs, session_register est obsolète et déconseillée...
http://php.net/manual/fr/function.session-register.php

Envoyé par Benjamin Delespierre

Sauf indication contraire, ça part sur fichier.

Effectivement, mais je pensais que ces fichiers avaient une limite de taille. Peut-être pas si j'en crois la doc. De toute manière, je n'ai pas accès au PHP.ini sur mon hébergement, donc ça aurait été limité de ce côté là
Mais ça m'a permit de découvrir http://fr2.php.net/manual/fr/functio...ve-handler.php qui permet de changer pas mal de choses sur la gestion des fichiers de session

Envoyé par Benjamin Delespierre

Je dirai, ça va dépendre de la taille de tes objets et des ressources consommées par la construction. Donc il faut voir si l'unserialize va plus vite que le constructeur, ce que tu peux faire avec un petit coup de profiling.

Je crois que je ne vais pas avoir le choix que de faire du profiling. Zut

Envoyé par Benjamin Delespierre

Je ne comprends pas du tout ce prototype.

J'ai écrit cet exemple rapidement et de tête. Personnellement, il ne me gène pas plus que ça.

[Benjamin Delespierre]

Effectivement, mais je pensais que ces fichiers avaient une limite de taille

Si c'est le cas, je ne l'ai jamais franchie et pourtant je suis pas tendre avec mes sessions

De toute manière, je n'ai pas accès au PHP.ini sur mon hébergement, donc ça aurait été limité de ce côté là

Il existe une documentation des propriétés du php.ini qui peuvent être définies au runtime ou dans le htaccess (c'est la colonne changeable qui t'intéresse).

Je crois que je ne vais pas avoir le choix que de faire du profiling. Zut

A mon avis, l'unserialize ira plus vite, mais que ça ne t'empêche pas de faire des tests
Juste un conseil pour l'optimisation: quel que soit la performance de ton algo, il ira moins vite en règle générale que les fonctions natives de PHP, par exemple, une manipulation de tableau avec des array_merge, array_combine, array_intersect et leurs petits copains va toujours plus vite qu'une boucle pour traiter ledit tableau.

J'ai écrit cet exemple rapidement et de tête. Personnellement, il ne me gène pas plus que ça.

Comment peut-il y avoir une notion de "current object" dans une méthode statique, et pourquoi s'appelle t'elle saveCurrentObject alors qu'elle prends un objet en paramètre. Elle devrait s'appeller saveObject, c'est ce que je voulais dire.

[Shikiryu]

Haha, ok, je suis pas le seul à utiliser assez intensivement les sessions

Je ne savais pas qu'on pouvait changer autant de chose dans un .htaccess.
Je ne suis pas sûr de la syntaxe. C'est bien :

Code :

php_flag nom valeur

?

(et pour les intéressés qui liront, cette page indique quels sont les constantes définies pour savoir quelles propriétés sont changeables et dans quelle endroit)

En gros, comme pour l'instant je n'utilise quasiment que des fonctions de base de PHP (unserialize/serialize, mise en session, etc...) ça n'influerai pas.

Effectivement, le "current" est de trop, surtout que je pourrais avoir plusieurs instances du même objet à "sauvegarder". C'est pas trop logique comme terme mais l'algo est acceptable.

[Benjamin Delespierre]

Oui c'est cette syntaxe, par exemple:

Code :

php_flag short_open_tag 1