|
Undo umesto Are you sure?
hteo bih da na novom projektu, poput gmaila, umesto dosadnih pitanja "Are you sure?" za akcije poput delete, omogucim da se akcija odmah izvrsi, ali da postoji i Undo opcija za slucaj greske.
Jel radio neko nesto tako? Kako najlakse implementirati ovako nesto u backend, da li postoji neka varijanta pametnija od klasicnog pristupa sa "deleted" flagom u bazi, i nekim cron jobom koji jednom dnevno pobrise sve markirane postove? |
Na jednom projektu davno sam pravio nesto slicno. Ne sjecam se svih detalja, ali je rjesenje bilo tako da je postojala tabela "recycle_bin" i u njoj polja id, datum brisanja, tip podatka (u smislu "post", "category", "media"...) i ko ga je obrisao... mozda i jos nesto. I naravno serijalizovani podaci koji se brisu.
Kada se brise, podaci se samo smjeste u tu tabelu i obrisu iz originalne/originalnih, a svaki objekat je imao metodu on_delete koji je tacno znao sta treba da radi prilikom brisanja svojih podataka, uz neophodne provjere. Kada se vraca iz korpe nazad, zavisno od sacuvanog tipa poziva se odgovarajuci on_undelete metod koji zna sta treba da uradi da bi iz korpe vratio podatke. Opet uz neke provjere. I na kraju par nekih stvari za odrzavanje tih podataka, kao brisanje cijele korpe, brisanje korpe samo za datog korisnika itd... To je OK radilo... |
nezgodan i lep task :)
mozda generirati obratne SQL-e? ukoliko user uradi 'move to folder' sto je (recimo) promena folder_id u bazi sa 3 na 5, onda da recycle bin sadrzi ID akcije i sql koji treba uraditi da bi se ponistila akcija (update sa 5 na 3) ovo nije bas zgodno ukoliko su neke akcije nadovezane, ali pri kratkim undo, bi trebalo biti ok |
Kada imaš nevezane stavke, onda nije problem. Recimo neke komentare na blogu ili nešto slično. Nastaje problem ako imaš više vezanih record-a.
Recimo, kada treba da obrišeš temu na forumu, normalno je da se obrišu i svi upisi u tabelu postova. Ako uradiš "undo" za tabelu gde su teme, oni postovi i dalje ostaju obrisani i tema je prazna. Tako bi onda trebao da napraviš neki grupni undo, da kada se vrati tema - da se vrate i svi obrisani postovi. Ja tu nemam pametno rešenje. A za ovaj "jednostavan" slučaj, imam tabelu trash u kojoj čuvam ceo objekat koji de obrisan, tip objekta, ko je obrisao, i kada. Pa kada neko gleda trash i uradi "undelete" pročitam koji je objekat bio i ponovo upišem taj record tamo gde je stajao. A namešten je cron da svaki dan briše iz "trash" tabele sve što je starije od 30 dana. |
Citat:
Edit: Ako nije neophodno, svakako izbjeći složene akcije. Npr. ne daš da se obriše kategorija u kojoj ima postova. "Rekurzija" mi uvijek diže alarm u glavi. |
Generalno se za "Undo" operacije koristi "Memento": http://www.oodesign.com/memento-pattern.html
|
Ja ipak glasam za "delete" flag. Ili eventualno malo poboljšanu verziju, gde je delete flag zapravo spoljni ključ na tabelu koja sadrži dodatne informacije o brisanju (tipa timestamp - da bi janitor cronjob znao šta da briše, eventualno id korisnika koji je izvršio brisanje), ili, još generalnije, na tabelu akcija.
Posebna tabela u koju se smeštaju obrisani objekti mi je skroz ružno rešenje, zbog normalizacije... @DT: Ovaj OO patern je zgodno znati, ali mislim da je ivanhoe mislio na ono što bi trebalo da se desi ispod haube... ;) |
Citat:
Konkretno, verovatno bi dodavali po rekord u nekoj "memento" tabeli kad god dođe do neke akcije koja menja stanje objekta (šta god da je u pitanju) i kad dođe do "undo" akcije pročitamo vrednost poslednjeg mementa i rekreiramo stanje pre poslednje korisnikove akcije. Pošto se radi o PHPu koji ne poznajem, bojim se da ne mogu da idem dublje ispod haube :) |
Ma sve je to ok, ali uzmi za primer baš brisanje. Šta bude sa objektom? Ako ga zaista brišemo, memento objekat nam nije od velike koristi. Ako ga ne brišemo (u smislu uništavanja instance), nekako moramo svetu da stavimo do znanja da je obrisan.
I šta je zapravo memento tabela? Kakvu strukturu ima? Da li se koristi posebna memento tabela za svaku klasu Originator objekta? Itd itd... |
Citat:
Pre brisanja, stanje "Inbox" objekta je: poruka 1. poruka 2. poruka 3. Kad korisnik izbriše poruku 2., kreiramo memento koji upamti da smo imali poruke 1, 2 i 3. Sad je stanje Inbox-a (obrati pažnju da poruku 2 fizički uopšte ne brišemo): poruka 1. poruka 3. Onda korisnik kaže: "uh, zeznuo sam se" i pritisne Undo. Pogledamo poslednji memento, vidimo da očekujemo poruke 1, 2 i 3, generišemo nov momento sa stanjem poruka 1 i 3 i Inbox izgleda opet: poruka 1. poruka 2. poruka 3. Provereno radi ;) |
Šta se dešava kada u inbox-u stoje poruke:
poruka 1 poruka 2 ... poruka 3749 pa onda obriše poruku 2 (kreira se memento) pa onda obriše poruku 37 (kreira se memento? Šta je sa prethodnim? Ovaj ga prepiše?) pa onda obriše poruku 381 (?) Da li postoji mogućnost višestrukog undo? Ako sam dobro razumeo to je undo samo za poslednju akciju? Ja sam više govorio o mogućnosti gde imaš neki "recycle bin" kao na desktopu, pa možeš u nekom trenutnku da vratiš šta god hoćeš a ne samo poslednju akciju... moja greška. |
Ne brišu se, nego imaš stek (ili tabelu) mementoa.
Npr. Stanje u trenutku 1: Inbox: Poruke 1, 2, 3, 4. Memento stek (ili tabela, štali): prazan Stanje 2 - izbrisana poruka 2 Inbox: Poruke 1, 3, 4. Memento: Memento1(Inbox: 1,2,3,4) Stanje 3 - izbrisana poruka 3 Inbox: Poruke 1, 4 Memento: Memento1(Inbox: 1,2,3,4), Memento2(1, 3,4) E sad, udarimo Undo. Recimo da (jednostavnosti radi) ne podržavamo Redo, inače bi kreirali nov memento i turili ga u redo stek. Pogledamo poslednji Memento - Memento2 i na osnovu njega kreiramo sledeće stanje: Stanje 4 - Undo Inbox: Poruke 1, 3, 4. Memento: Memento1(Inbox: 1,2,3,4) Opet undo? Može. Opet pogledamo poslednji (tj jedini) Memento - 1. Stanje 5 - drugi undo Inbox: Poruke 1, 2, 3, 4. Memento: prazan |
Nemam pojma... meni deluje da to nije za zahtevnije ili komplikovanije stvari, naročito sa više usera. Suviše dodatnih stvari se radi (i troši space i time) zarad jednog relativno jednostavnog feature. Reče čovek da radi nešto "poput gmaila", mislim da je to uvaj memento pattern loš(ije)e rešenje.
|
^Slažem se.
Nemanja, pa to stvarno izgleda naopako :)) Svaki put kada neko obriše jednu poruku, ti zapisuješ komplet stanje pre. Pa šta ako imaš inbox sa 100,000 poruka? Nije li jednostavnije u taj memento zapisati ono što je obrisano? I kad radiš undo samo ideš redom unazad po toj tabeli i poruke opet markiraš kao "vidljive" u inboxu.. |
Verujte mi da su u praksi većina undo sistema zasnovana na mementu. E sad, varijanta koju sam opisao (sa potpunim stanjem) je najjednostavnija i najskuplja; uvek možeš da čuvaš diff umesto kompletnog stanja kad to ima smisla.
|
hmm, ako se cuva samo diff, to se onda svede manje vise na ovo sto su zira i blues opisali, recycle bin tabela, zar ne?
@jablan: to sa spoljnim kljucem ka recordu gde su detalji o brisanju mi se svidja, cini mi se kao najjednostavnije resenje. Nekako mi se cini kao nepotreban posao da premestam podatke iz jedne tabele u drugu ako mogu samo da update-ujem jedno polje umesto toga. Plus ovako sa delete flagom ne moram da se mucim da zadrzim ref. integrity, odnosno ne moram da brinem o premestanju celokupnog relacionog stabla u drugu tabelu, nego samo markiram record ili vise njih kao obrisane, i iskljucim ih po tom uslovu iz bitnih selecta. Vracanje neke strukture nazad mi deluje kao velika glavobolja, radje se ne bih petlja sa tim... Hvala svima na idejama :) |
Citat:
Ono o čemu se ovde (bar mi se čini) govori, je druga situacija - originatora je mnogo, zapravo svaki red svake tabele može biti originator i onda se situacija dosta komplikuje jer imaš dve mogućnosti - ili da praviš neku generičku tabelu za mementa u koju ćeš smeštati neke serijalizovane podatke o izmenama (što je blagi užas za kodiranje), ili ćeš imati po jednu memento tabelu za svaku klasu originatora, što je blagi užas za održavanje. Opet da naglasim, sve ovo pričam ne iz iskustva, već iz spekulacije. A poslednji put kad sam radio nešto slično (CMS), svi objekti su bili nasleđeni iz neke osnovne klase, i imali smo relativno jednostavan recycle bin. |
Citat:
|
| Vreme je GMT +2. Trenutno vreme je 12:23. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.