Bonjour,
Je suis en train d'écrire un site web qui devra accéder à une base de données Oracle via les fonction oci_xxxxx. La première fonction que j'appelle est oci_pconnect(...) qui me permet de créer la connexion, et renvoie un type "resource".

Comme toutes les pages qui doivent accéder à la base vont avoir besoin de cet objet, je voudrais le stocker sous forme d'un cookie. Pour cela il faut que le convertisse sous forme d'une chaîne de caractères (avec le cast explicite (string) cela marche bien) pour le stocker dans le cookie.

Mais lorsqu'une page en a besoin pour faire un accès à la base, il faut qu'elle puisse reconvertir cette chaîne de caractères en un type resource. Le cast ne se fait pas en automatique. Et je ne sais pas comment le forcer ((resource) n'existe visiblement pas). Quelqu'un connaîtrait-il la solution?

Merci d'avance.

Slt ,

Je te conseil plutôt de regarder du coté du design pattern "Singleton" qui te permet d'avoir une seul instance durant toute "l'exécution" de ton code .

sinon, voilà des infos sur la sauvegarde d'objets en session .


Ch.

Je viens de regarder les liens. Concernant le singleton, je ne comprends pas comment cela pourrait marcher en version "inter-pages". Il crée un objet unique dans le PhP mais une fois qu'on change de page, donc de contexte PhP, l'objet s'est "évaporé" non?

Concernant l'option serialize/unserialize c'était une bonne idée. Malheureusement en essayant et en lisant la doc associée il apparaît que cela ne marche pas. La doc précise "que cela marche sur tous les type SAUF les ressources" .

Effectivement ,à la fin de ton script , l'objet n'est plus , donc la ressource qu'il contient non plus ...

La connexion à ta base devra donc se faire à chaque page ...

Cependant , si tu veux garder les valeurs des attributs de ton objet , tu peux sérialiser et deserialiser .

tu supprimes ta ressource à ta base à la sérialisation grâce à la méthode magique__sleep() , et tu te reconnectes à la deserialisation grace à la méthode magique __wakeup().

Tu peux utiliser une connexion persistante à ta base , qui met en cache ta ressource , pour la ressortir lorsque tu tente de te reconnecter ... je ne suis pas fan de ce genre de méthode , si tu l'utilises , n'oublies pas de supprimer/libérer cette ressource lorsque tu n'en n'a plus besoin .
Je pense que tu ne gagneras rien à utiliser une connexion persistante .
Infos

Le singleton , te permet par exemple de ne faire qu'une connexion à ta base de données , même si tu as besoin à deux endroits différents ( d'une même exécution ) d'accéder à la base .

Celà te permet d'avoir une seule instance , donc un seul objet durant toute l'exécution de ton code .

Un objet avec un design pattern Singleton , ne peut , normalement pas être directement créer via un "new" , et ne peut être cloné .

L'utilisation pour la connexion à une base , n'est qu'un exemple , il peut être utile dans bien d'autres cas .

Ch.

Ben l'idée de la connexion persistante était justement de pouvoir passer uniquement la ressource d'une page à l'autre. Je pars d'une page Login/password qui crée la connexion et en la rendant persistante, si j'arrive à passer la ressource, je n'ai plus besoin des infos Login/password.

En temps normal j'aurais fait un login/password fixe pour la connexion et une gestion manuelle de droits utilisateur à partir d'un login/password autre. Ce qui m'aurait permis d'utiliser toute la mécanique des sessions en ne conservant que l'ID de session. Mais là il se trouve que je n'ai aucun contrôle sur la base. C'est pour cela que je pensais à la connexion persistante.