Archief - PHP: objecten in sessie steken

killgore · 22 mei 2006

Omdat die session handler het dan in db opslaat en niet jij, hoe kan die session handlers weten welke velden jij hebt, of je gaat gewoon een object rechtstreeks in je db steken? Of bedoel je via die wakeup functies, je gaat het 2x opslaan of zo (eens in sessie en eens in db).
Levensduur van uw sessie zelf instellen? Geen slim gedacht imho, maar je doet maar.

PC_Freak · 22 mei 2006

hoe kan die session handlers weten welke velden jij hebt

Daarom juist dat sleep en wakeup handig is, je bepaalt zelf de methode hoe het object wordt opgeslagen in de database, de uiteindelijke data opslaan gebeurt dan door uw session handler. Je slaat dan juist niets twee keer op, want in dit geval zitten sessies in de database.

Levensduur van uw sessie zelf instellen? Geen slim gedacht imho, maar je doet maar.

Dus je bent van plan sessies eeuwig te laten duren? Nog een veel slechter gedacht. Ook als je geen sessies gebruikt voor een winkelwagentje moet dat winkelwagentje ooit gepurged worden als de gebruiker de goederen niet definitief "aankoopt". Wanneer en hoe bepaal je terug zelf in de garbage collector van de sessie.

Als je dit correct schrijft heb je een perfect systeem en dit kan zelfs perfect OO, met de mogelijkheden die PHP voorziet zonder het wiel te moeten heruitvinden met eigen sessiesystemen ed.

killgore · 23 mei 2006

Bedoel jij dat je met session_set_save_handler werkt?
Want ik snap je niet goed.

Je zou in __sleep en __wakeup db storage & restore doen. Maar deze worden enkel opgeroepen bij het serializen, dus heb je zowiezo EEN geserialisede component nog steeds nodig en wordt je db-systeem vrij nutteloos?

edit: nuja, ik begrijp ongeveer wat je bedoelt (niet perfect jouw implementatie, maar het systeem errond, ik werk gelijkaardig), maar daar ga ik nog deftig mee akkoord, maar er is wel een verschil tussen dat en de manier van opslaan die hier boven werd vermeld he

de "steek het er maar in en alles komt goed" manier.

PC_Freak · 23 mei 2006

Wel, je hebt een object. Op het moment dat je deze opslaat in de sessie (ik weet niet of serialize in dit geval nog handmatig moet gebeuren) zorgt sleep ervoor dat enkel de nodige velden overblijven. De session handler slaat dan alles (in $_SESSION) op in de database en zorgt ook voor timeouts enz.

Op de volgende pagina moet je dan niets meer doen dan de sessie verderzetten en je kan meteen terug het object verder gebruiken (als wakeup zijn werk doet).

Ik heb dit nog niet in de praktijk getest maar volgens mij is dit een deftig systeem zonder dat er zelf een sessiesysteem moet worden geschreven.

killgore · 23 mei 2006

Neen dus

.

Het blijft de nadelen hebben van wat ik hiervoor vermelde. Namelijk dat je nog steeds afhangt van de levensduur van je sessie, je nog steeds een deel in je sessie-global opslaat, die zoals ik zei vrij simpel kunnen overschreven worden, ... .

Ik had het op wel degelijk een "eigen" sessie-systeem schrijven (natuurlijk gebruikmakend van de gewone session-functies), imho de beste oplossing, zolang je natuurlijk gc niet vergeet

.

passero · 23 mei 2006

dus eigenlijk een soort van sessie tabel aanmaken in uw DB waar ge de nodige velden in opslaat en aan de hand va nde user die ingelogd is kunt ge de juiste sessie ui de db halen...

PC_Freak · 23 mei 2006

Namelijk dat je nog steeds afhangt van de levensduur van je sessie, je nog steeds een deel in je sessie-global opslaat

Euh net als bij een custom sessiesysteem bepaal je zelf wat wanneer verloopt als je een custom session handler gebruikt. Een sessie kan niet zomaar verlopen of een levensduur hebben tenzij je die zelf maakt. De data gaat enkel verloren als je session_destroy() gebruikt en zo uw zelfgeschreven destroy fallback wordt aangeroepen. Idem voor de gc bepaal je dit zelf.

En zoals ik zeg, alles in $_SESSION is afkomstig van uw database. Als je manueel een object maakt met data uit de database dan heb je dit ook tweemaal. Wat is het verschil dan?

killgore · 23 mei 2006

omdat niet alles in session van je db afkomstig is zoals jij denkt.

De opslagmethode TUSSEN 2 pagina's (daar draait het nl. om) gebeurt bij jou via zowel sessies als een db. Als jij je sessie-data kwijt bent ben je ook niets meer met je db-data.

PC_Freak · 23 mei 2006

Bij mijn weten, de enige sessie data die er dan is is de cookie met het sessie-ID. Op de schijf wordt alleen sessie-data opgeslaan als men standaard sessies gebruikt (meestal /tmp) of tenzij men dit natuurlijk geschreven heeft in de custom handler.

Uit de manual:

session_set_save_handler() sets the user-level session storage functions which are used for storing and retrieving data associated with a session. This is most useful when a storage method other than those supplied by PHP sessions is preferred. i.e. Storing the session data in a local database.

Als er onderhands toch nog ergens anders sessie-data wordt opgeslagen, dan zou ik daar wel eens een bewijs willen van zien, of een confirmatie ergens op het web.

servi · 23 mei 2006

killgore zei:
De personen die klagen over dergelijke performantie zijn typisch de mensen die iets coden als:

PHP:

$array = array(...); for($i=0; $i < sizeof($array); $i++) { ... }

ik zou zo niet willen beweren dat dit trager is dan

PHP:

$tabel = array(...);
$grootte = sizeof($array);
for ( $i = 0; $i < $grootte; $i++) {
...
}

de meeste interpreters/compilers zijn veel slimmer dan je denkt en zullen automatisch een variabele bijhouden.

bij c++ is bij de overgrote meerderheid van de compilers :
dit

Code:

for (unsigned int i =0; i < strlen(woord); i++ )
...

identisch aan

Code:

unsigned int grootte= strlen(woord);
for (unsigned int i=0; i < grootte; i++)
...

deze compilers zullen immers zelf die variabele creëren.

En het lijkt me weinig onwaarschijnlijk dat de interpreter van php zo lomp is om daar geen variabele van te maken.

killgore · 23 mei 2006

Toch wel (mssch in de laatste versie niet, zou ik eens moeten controleren)

.
Edit: in de php5 versie die ik hier staan heb is er wel degelijk nog een verschil ... .

@Freak: je object wordt altijd opgeslagen op 1 of andere manier he. Hoe gaat pagina B anders weten wat voor variabele pagina A was? Dit wordt zoals je zegt std in files in je /tmp folder opgeslagen. De cookie info bevat idd normaal enkel SESSION_ID, maar daar had ik het niet over.
Maar jij werkt nu weer met session_set_save_handler, ik had je al gevraagd of je dat bedoelde ma je antwoorde daar niet op. Zoals ik al zei: dit systeem is een totaal verschil met het gewone php-session handling systeem waar ik het op had en implementeert een eigen sessie systeem, daar is niets mis mee natuurlijk, omdat je daar de technieken die ik hiervoor noemde min of meer kon toepassen en problemen +/- kon wegwerken (ik vind dat er betere methoden bestaan, mja, dat is nog iets anders

).

PC_Freak · 23 mei 2006

Ik heb het uiteraard al de hele tijd op een custom save handler, anders kan je niet sessies in de database opslaan tenzij je zelf iets schrijft.

Als je alles in de database opslaat is $_SESSION = database. Ik sla een object op in $_SESSION (dmv serializen en sleep worden enkel bepaalde velden behouden) en dit wordt opgeslagen in de database. /tmp wordt niet gebruikt aangezien je een custom save handler hebt.

Databaseopslag implementeren in sleep en wakeup is nutteloos aangezien dat enkel wordt gebruikt voor serializen, iets wat je niet gaan doen als je het direct opslaat in de database ipv in de sessie.

killgore · 23 mei 2006

PC_Freak zei:
Als je alles in de database opslaat is $_SESSION = database. Ik sla een object op in $_SESSION (dmv serializen en sleep worden enkel bepaalde velden behouden) en dit wordt opgeslagen in de database. /tmp wordt niet gebruikt aangezien je een custom save handler hebt.

Databaseopslag implementeren in sleep en wakeup is nutteloos aangezien dat enkel wordt gebruikt voor serializen, iets wat je niet gaan doen als je het direct opslaat in de database ipv in de sessie.

Inderdaad, daarom dat ik ook zeg dat ik met DAT systeem akkoord ga.

Jij begon me initieel aan te vallen omdat ik het gewone session systeem van php afbreek, groot verschil hoor.

Het enige nadeel dat ik hier nog zie is inderdaad (ik vind dat nadeel) het feit dat niet de klasse zelf voor opslag zorgt, maar gewoon moet meegeven welke waarden er voor moeten worden opgeslagen. Maar dat is dan ook het enige.

PC_Freak · 23 mei 2006

Blijkbaar heb ik ergens over gelezen dat je het niet had over een custom session handler (save handler dus).

Archief - PHP: objecten in sessie steken

killgore

Legacy Member

PC_Freak

Legacy Member

killgore

Legacy Member

PC_Freak

Legacy Member

killgore

Legacy Member

passero

Legacy Member

PC_Freak

Legacy Member

killgore

Legacy Member

PC_Freak

Legacy Member

servi

Legacy Member

killgore

Legacy Member

PC_Freak

Legacy Member

killgore

Legacy Member

PC_Freak

Legacy Member