Operace zpět k provedené AKCI
- Mesiah
- Člen | 240
Zdravíčko,
na úvod se chci omluvit za duplicitní
post, ale zdá se že na AJ forum moc lidí nechodí…
Každopádně, zajímá mě, jak a jestli vůbec řešíte Undo operaci?
Když se nad tím zamyslím, tak informace, které bych měl ukládat jsou
datetime, akce (modul:presenter:akce), hodnota před změnou (ideálně
binární tvar (base64)), hodnota po změně (taky binární tvar(base64)).
Následně tyto údaje potřebuji někde uložit po určitou dobu (relační db,
memcache, sessions?), další otázka je jak bych mohl zajistit automatické
provádění uložení historie po odeslání formuláře, či obsluze signálu
(callback/event?).
Nebo tyhle změny řešit na úrovni db – logovací tabulka(y) a trigerry nad
tabulkami?
Máte nějaké zkušenosti s undo o které se můžete podělit?
Díky!
PS: omlouvám se za caps-lock na slovo „akci“ – ujelo mi to a nevšiml jsem si toho.
Editoval Mesiah (23. 1. 2014 16:12)
- honos
- Člen | 109
Podle me je up jedno jestli to provedes pomoci trigeru nepo nejakyho
eventu/udalosti ale.
Pri pouziti triggeru mas pouze omezene mnozstvi dat, vlastne jen ty co predas
v SQL dotazu kdyz to pri pouziti udalosti mas vetsi moznosti. asi jako
nejvhodnejsi moznost se ale podle me jevi SESSIONS. Navic pokud jsou data
ukladana jenom docasne, napriklad nez uzivatel provede refresh nebo prejde na
jinou stranku tak ta data asi odstranis, ale jak potom bys resil otazku kdy
uzivatel ma otevrenych vice panelu na stejnou domenu a na jedne strance provede
nejakou akci a v druhym panelu provede refresh nebo prejde na jiny odkaz
v ramci domeny. Hrozi riziko ze provedene upravy v prvnim panelu uz nepujde
vratit zpet. Dalsi otazkou je proc si chces ukladat data zmenena data spolecne
s puvodnimi daty kdyz zmenena data jiz budes mit v databazi? Ukladat stara
data spolecne s #ID a vygenerovanym #HASH do SESSIONS a pomoci tohoto #HASHe
s nimi nasledne manipulovat. Nebo jeste lepe misto #HASHe pouzivat
primo #ID.
- honos
- Člen | 109
Jan Endel napsal(a):
To co hledáš jsou pravděpodobně tzv. Auditorské tabulky
V tomto pripade se jedna o trvale nebo o dlouhodobejsi uchovani zmen, jaka si historie.. Vtomto pripade ano, pouzit databazi nebo souborovy system.
@mesiah tak me napada ze pro pripad ze uzivatel otevira domenu z vice panelu je lepsi pouzit ten #HASH vygenerovany v php za pouziti treba url + timestamp a nebo podobne kombinace a nasledneho zacleneni tohoto #HASHe do dotazu na server pri uprave. nevim jestli mas na mysli upravu nejakyho artiklu nebo treba odstraneni prispevku pomoci AJAXu ala facebook..
- Mesiah
- Člen | 240
Takový klasický případ je v administraci eshou – uživatel správce
změní obrázek produktu a vypíšu mu hlášku ve stylu „Úpravy byly
úspěšně provedeny, pokud Vám změny nevyhovují, můžete je vrátit zpět .“, ten stejný princip bych použíl na editaci
popisku, ceny, atd.
Osobně jsem nabyl dojmu, že pro tyto účely budou nejlepší auditorské
tabulky (btw, na tohle téma se hezky rozpovídal
Bohužel-zapomněl-jsem-jak-se-jmenuje na PixDevDay 2013 z csfd) s tím, že
u každé entity budu uchovávat ID auditorského záznamu – blbý na tom je
to, že budu muset hodnoty zapisovat v before triggeru a pokud nastane
problém, tak se mi v podstatě zbytečně zapíší hodnoty.
Tím se mi vyřeší problém s taby a pokud uživatel bude chtít vrátit
změny, budu vědět jakou akci provést a jaké hodnoty vrátit.
Pokud Vás ale napadnou případné slabiny tohoto řešení, tak budu rád,
když mě upozorníte…
Editoval Mesiah (23. 1. 2014 21:22)
- honos
- Člen | 109
No, mě ještě napadá že by jsi mohl použit auditorské tabulky
ale nějakým způsobem, třeba sloupec returned, také použit
indikátor že změna byla provedená (vracená) aby se po
reloadu nebo vraceni změn se již
nezobrazovala možnost vrátit zpět.
Jednak budeš mít co chceš a jednak můžeš historii změn ukládat po
delší dobu.. :-| ?
Editoval honos (27. 1. 2014 10:38)