Diskuze: Vrátenie novej identity

Dominik Gavrecký

Tvůrce

Dominik Gavrecký:12.8.2016 23:50

Ahojte,

pracujem na jednom väčšom projekte v nette a natrafil som na celkom pre mňa závažný problém. Vytvoril som si editáciu užívateľa kde si užívateľ dokáže meniť svoje údaje a pod. (aké prekvapenie ) No však po zmenení údajov sa do DB zapíšu ale neviem ako ich po editácii znova nahrať do triedy user.

Písal som aj na fórum Nette kde mi povedali že ho mám odhlásiť s nejakou flashmessage čo v mojom prípade neprichádza do úvahy.

Ďakujem

Odpovědět

12.8.2016 23:50

Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.

Martin Konečný (pavelco1998)

Tvůrce

Martin Konečný (pavelco1998):13.8.2016 0:14

Proto zásadně do Identity ukládám jen ID uživatele, které se nemění, nic víc
Problém je, že se ty údaje ukládají do session, takže pokud chceš hned vidět změnu, musíš to do session znovu nacpat, na což bude asi nejlepší uživatele odhlásit a znova přihlásit (dobrá blbost co?).

Nahoru Odpovědět

13.8.2016 0:14

Aktuálně připravuji browser RPG, FB stránka - https://www.facebook.com/AlteiraCZ

hitzoR

Člen

hitzoR:13.8.2016 3:55

Tohle by mělo fungovat:

$this->user->getIdentity()->property = 'propertyValue';

Pokud to děláš jinde než v presenteru (třeba v nějaké komponentě), tak si do ní injectni Nette\Security\User a přes getIdentity() získej identitu, kde pak jednoduše můžeš měnit hodnoty.

Nahoru Odpovědět

13.8.2016 3:55

Dominik Gavrecký

Tvůrce

Dominik Gavrecký:13.8.2016 9:31

V tom prípade sa ukrytiš o používanie triedy user

Nahoru Odpovědět

13.8.2016 9:31

Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.

Dominik Gavrecký

Tvůrce

Dominik Gavrecký:13.8.2016 9:33

Otestujem a dam vedieť

Nahoru Odpovědět

13.8.2016 9:33

Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.

Martin Konečný (pavelco1998)

Tvůrce

Martin Konečný (pavelco1998):13.8.2016 11:52

Nechápu, co tím myslíš. Třídu user stejně používám jen pro získání jeho ID a zjištění, jestli je přihlášen. Víc nepotřebuju - seženu si to z databáze.

Nahoru Odpovědět

13.8.2016 11:52

Aktuálně připravuji browser RPG, FB stránka - https://www.facebook.com/AlteiraCZ

hitzoR

Člen

hitzoR:13.8.2016 12:11

A není to trochu overkill při každém requestu, kde potřebuješ něco od přihlášeného uživatele, sahat do databáze? Jasně, je to většinou jen jeden dotaz, ale určitě je úspornější to mít v identitě a tahat to ze session. A tím spíš, když ti tam chodí hodně lidí a když máš (a to jako že bys měl mít) na každé stránce vypsané minimálně username nebo email, aby uživatel viděl, že je přihlášený a pod jakým účtem.

Nahoru Odpovědět

13.8.2016 12:11

Dominik Gavrecký

Tvůrce

Dominik Gavrecký:13.8.2016 13:00

Presne ako hovorí Hitzor

Nahoru Odpovědět

13.8.2016 13:00

Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.

Martin Konečný (pavelco1998)

Tvůrce

Martin Konečný (pavelco1998):13.8.2016 13:30

No jestli je pro tvou databázi problém udělat jeden jednoduchej SELECT podle primárního klíče, tak je asi někde chyba na tvé straně
Když pak tomu uživateli administrátor změní email, řešíš to jak? Tomu uživateli se to musí ihned projevit, takže musíš někde držet informaci, že to ten admin upravil a musíš toho uživatele znovu přihlásit. Kde tuto informaci uchováváš?

Pozn.: nemusí jít zrovna o mail, ale o jakoukoliv jinou informaci, kterou zobrazuješ na každé stránce. Jde mi o to, jak má aplikace poznat, že se danému uživateli ta informace změnila a musí se teda znovu do té session uložit.

Nahoru Odpovědět

13.8.2016 13:30

Aktuálně připravuji browser RPG, FB stránka - https://www.facebook.com/AlteiraCZ

hitzoR

Člen

hitzoR:13.8.2016 13:35

Zkus si přečíst, co sem napsal výše. ;-) Odhlašovat a znovu přihlašovat uživatele fakt není třeba.

A problém pro databázi to není, ale až se někdy dostaneš k projektu, kde budou v jednu chvíli ke stránkám přistupovat desetitisíce lidí a budeš mít server třeba na jiném fyzickém serveru než kde ti běží PHP, tak ten jeden select může ovlivnit načítací čas klidně o sekundu, což je fakt hodně, ikdyž se to nezdá. Proč myslíš, že se dělají ORM, které pokudmožno posílají do databáze jenom obyčejné jednoduché selecty bez jakýchkoliv joinů a až pak si to v PHP spojí dohromady?

Nahoru Odpovědět

13.8.2016 13:35

Martin Konečný (pavelco1998)

Tvůrce

Martin Konečný (pavelco1998):13.8.2016 13:37

Možná je to jen má neznalost - ale když tu informaci (třeba email) změní uživatel třetí strany (třeba admin), jak pak tomu přihlášenému uživateli přepíšeš tu informaci v session?

Nahoru Odpovědět

13.8.2016 13:37

Aktuálně připravuji browser RPG, FB stránka - https://www.facebook.com/AlteiraCZ

TomasGlawaty

Člen

TomasGlawaty:13.8.2016 15:54

S tvojí myšlenkou ohledně ORM nesouhlasím. ORMka nemají s rychlostí nic společného. Nabízejí odstínění od databázové vrstvy, určitou abstrakci a spolehlivost ohledně přenášených dat oboumi směry. A to právě na úkor rychlosti...

Nahoru Odpovědět

13.8.2016 15:54

Marian Benčat

Člen

Marian Benčat:13.8.2016 17:15

Vetsi blbost jsem asi v zivote necetl.. tedy poud to nebyla ironie...

ORMka jsou ve velkem poctu stejne rychle jako kdyz to napises rucne a ve velkem neskutecne pomalejsi, nez kdyz to napises rucne, protoze jim proste chybi semantika a nevi co chces udelat. Take tedy hode zalezi na tom jak napises dotaz v tom danem jazyce.. a je jedno jestli je to LINQ, nebo treba DQL..

Co me ale pobavilo jeste vic je to, ze pises, ze daji jen jednoduche dotazy a pospojuji si to az v aplikaci,.. to je asi jeste mnohem vetsi bullshit, nez to prvni.. Pominu zde, že se tu bavíte o PHP, které to pospojovani asi udela jen tak milionkrat pomaleji a sezere pri tom 40GB pameti, vzhledem k tomu, jak je vse v pameti v PHP realizovano pres hashtable a jak PHP totalen neumi zachazet s pameti a povim tu, ze i v jazyce, co patri do roku 2000+ je todle znatelne pomalejsi., musis si posilat data navic,tvuj jazyk musi skakat poo pameti, navic ty jednotlive data nema v pameti tak optimalizovane ulozene jako DB server, takze mas silenej cache miss ratio a tunu dalších blbosti...

a proto právě ORM obaluješ ještě nějakou dal vrstvou, třeba repozitáře a query objecty, aby když ti dojde k výkonnostnímu problému, aby si jen vevnitř mohl vyměnit použití ORM za něco jiného,,,. třeba přímý SQL command, nebo za volání stored procedury.

Editováno 13.8.2016 17:17

Nahoru Odpovědět

13.8.2016 17:15

Totalitní admini..

Dominik Gavrecký

Tvůrce

Dominik Gavrecký:13.8.2016 18:03

chlapci myslíš že to vôbec nesúvisí s témou ... Mohli by sme sa vrátiť k téme ?

Napadlo ma ešte jedno riešenie ak by som využil:

$this->user->getIdentity()->property = 'propertyValue';

tak pri editácii užívateľa adminom by som ho odhlásil ale nette túto možnosť nemá aspoň som ju nenašiel ...

Nahoru Odpovědět

13.8.2016 18:03

Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.

Dominik Gavrecký

Tvůrce

Dominik Gavrecký:15.8.2016 11:37

Stále aktuálne

Nahoru Odpovědět

15.8.2016 11:37

Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.

Nejčastěji vyhledáváné

Diskuze: Vrátenie novej identity