Witajcie.
Jakie są Wasze pomysły lub sprawdzone rozwiązania realizacji zagadnienia pt. "ten rekord jest już edytowany przez innego użytkownika".
Wątek przeniesiony 2020-09-22 19:24 z PHP przez cerrato.
Witajcie.
Jakie są Wasze pomysły lub sprawdzone rozwiązania realizacji zagadnienia pt. "ten rekord jest już edytowany przez innego użytkownika".
Po pierwsze lektura nt "optimistic locking" i "pesymistic locking"
Obie mają zady i walety.
W optymistycznym pojawia sie pole timestamp (niekoniecznie taka implementacja w bazie, raczej zwyczajowa nazwa), można z niego to i owo wyciągnąć.
Tak lektura tych zagadnień już była. Przyjmijmy pesymistic locking lecz kwestia zerwania połączenia z bazą, przerwania edycji danych przez użytkownika (nieoczekiwanie)
dokładnie takie sytuacje, zastanawiam sie jak to sensownie rozwiązać
artbski napisał(a):
Tak lektura tych zagadnień już była. Przyjmijmy pesymistic locking lecz kwestia zerwania połączenia z bazą, przerwania edycji danych przez użytkownika (nieoczekiwanie)
Lub pójścia do kibla, potem coś zawróciło ...
Z mojej własnej perspektywy pesymistiuc jest (jak zauważasz) zbyt twardy na wiele życiowych scenariuszy (opis na blogu, faktura, PROSTE dokumenty). Osobiście wydaje byłby uzasadniony jedynie w jakiś ważnych życiowych sprawach 1)
Po drugie (trochę?) źle się sprzęga z filozofią aplikacji webowej, kolejny request z tej samej sesji zwykle trafi na inne połączenie SQL, czyli sam dla siebie będzie konkurentem (lepiej się sprawdzał w destopach)
Nie należy się bać optimistica. Choć zależy o jakich danych mowa, i jakie prawdopodobieństwo konfliktu. Zawsze trzeba to ergonomicznie obudować w UI.
Chodzi konkretnie o aplikację typu ERP (np. faktury) z interfacem webowym.
artbski napisał(a):
Chodzi konkretnie o aplikację typu ERP (np. faktury) z interfacem webowym.
Tak często - wręcz na wyścigi - ludzie babrają w starych, już istniejących fakturach?
Bo przecież (w sensownym projekcie) nie dotyczy to nowej faktury
Nie chodzi o częstotliwość i wyścig. Chodzi o wielodostęp i niemożliwość jednoczesnego edytowania przez wielu użytkowników tego samego dokumentu.
Jest wiele takich przypadków mniej lub bardziej uzasadnionych aczkolwiek są. Systemu zawsze musiały i będą musiały być głupoodporne.
artbski napisał(a):
Nie chodzi o częstotliwość i wyścig. Chodzi o wielodostęp i niemożliwość jednoczesnego edytowania przez wielu użytkowników tego samego dokumentu.
Jest wiele takich przypadków mniej lub bardziej uzasadnionych aczkolwiek są. Systemu zawsze musiały i będą musiały być głupoodporne.
W dobrym ERP szycie tego na poziomie faktury, bez żadnych uprzednich decyzji architektonicznych, bez seniorów itd ...
Jeśli możesz odnieść się merytorycznie do tematu to bardzo proszę jeśli nie to nie nabijaj sobie kosztem tego postów. To nie ma sensu, aczkolwiek taka niestety jest rzeczywistość na forach i nie spodziewałem się więcej.
Korzystasz z jakiegoś frameworka, czy piszesz w czystym PHP?
Możesz dodać do tabeli z rekordami kolumny typy lock_time, user_id. Przy wejściu na rekord zapisujesz id usera i czas. Po jakiejś akcji zakończenia działań czyścisz te wpisy. Dodatkowo ustawiasz task w systemie który czyści jakieś locki po określonym czasie na wypadek dłuższej lub nieskończonej przerwy.
Od cała filozofia. Można to nazywać podejściem pesymistycznym ale z tego co piszesz czegoś takiego potrzebujesz.
Korzystam z frameworka Codeigniter z modyfikacjami dla własnych potrzeb. Większość frontendu w javascript. Rozpatrywałem już chyba wszystkie możliwe podejścia do tego tematu i w zasadzie napisałem ten post po to właśnie, aby dowiedzieć się jakie Wy stosujecie rozwiązania tego tematu. To o czym piszesz wydaje mi się właśnie najbardziej sensowne do tego celu. Uruchomienie crona i zdejmowanie ewentualnych blokad po określonym czasie.
Ile przypadków tyle rozwiązań. Np w przypadku wykrycia ze dokument sie zmienil w miedzyczasie wywalasz uzytkownikowi error sorry ale dokument sie zmienil zacznij prace od nowa :).
Ja tak w kilku systemach robiłem. Działa, pozwala wyświetlić komunikat typu: użytkownik z edytuje rekord itd.
To co opisuje @Schadoow też jest jakimś podejściem, ale osobiście nie preferuję wkurzania użytkowników.
Tak dokładnie, jeśli cron usunie z tabeli "lock" dla użytkownika w danej sesji na konkretnym rekordzie, wówczas podczas próby zapisu formularza pojawi się stosowny komunikat "że sorry".
Natomiast sensownym byłoby również uruchomienie funkcji podtrzymującej (przedłużającej) czas blokowania. Wówczas aktywnego (powolnego w swej pracy) użytkownika nie spotkałaby niemiła niespodzianka.
Ja po prostu dobieram czas empirycznie i ustawiam takie taaki na 15 czy tam 30 minut. Nie miałem tak długich działań użytkowników per rekord żeby taki czas przedłużać. Ale to już musisz sam zweryfikować.
Jakby nie było, integralność danych jest istotniejsza niż poziom niezadowolenia użytkownika :-)
@jurek1980: zresztą co za problem dać ten czas jako parametr, który admin danej instalacji może zmienić, jak okaże się, że 15 minut to za mało dla Bożenki z księgowości albo Miecia z zaopatrzenia?
Moi użytkownicy potrafią wprowadzać fakturę ponad 2 godziny i nie dlatego, że są powolni, ale dlatego że faktura ma ok 1000 pozycji... - Panczo 51 minut temu
Problem z lockiem dotyczy tylko "starych" faktur (chyba, ze projekt leży i kwiczy)
Fakt - dotyczy to dokumentów już wystawionych i poddanych edycji. Natomiast dla uściślenia nie dotyczy to li tylko dokumentów typu "faktura". To tylko przykład dla zobrazowania jakiego rodzaju danych dotyczy to zagadnienie. Edycja pojawia się również w przypadku dokumentów typu "raport bankowy", "raport kasowy", etc. etc. a "rozjazd" danych np. rozrachunkowych i późniejsze ich uzgodnienia nie należą do przyjemnych historii.
artbski napisał(a):
Fakt - dotyczy to dokumentów już wystawionych i poddanych edycji. Natomiast dla uściślenia nie dotyczy to li tylko dokumentów typu "faktura". To tylko przykład dla zobrazowania jakiego rodzaju danych dotyczy to zagadnienie. Edycja pojawia się również w przypadku dokumentów typu "raport bankowy", "raport kasowy", etc. etc. a "rozjazd" danych np. rozrachunkowych i późniejsze ich uzgodnienia nie należą do przyjemnych historii.
W tej kategorii, i przez słówko ERP, to oczekiwany jest mechanizm np śladu rewizyjnego (zapis do inteligentnego loga)
Wyżej koledzy wskazują na 'lock' m.in. z identyfikacją użytkownika.
Wydaje mi się, ze ta grupa (pewnie w niej mieści się więcej zazębiających się zagadnień) powinna mieć wspólny projekt, być jednym z filarów ERP.
Edycja pojawia się również w przypadku dokumentów typu "raport bankowy", "raport kasowy", etc. etc. a "rozjazd" danych np. rozrachunkowych i późniejsze ich uzgodnienia nie należą do przyjemnych historii.
Nie wyobrażam sobie bez middle-ware, na surowej bazie SQL. Oczywiście nie zaniedbując wszelki reguł integralności SQL, ale SQL to za mało (szkolny przykład: nie da się zrobić granta do niektórych wiersz tabeli, albo granta warunkowego)
Lock możesz odświeżać jeśli sesja jest aktywna (użytkownik coś robi).
Jeśli nie jest aktywna, przestajesz odświeżać timestamp i demon łapie taki stary lock i usuwa.
Do tego blokada optymistyczna.
jurek1980 napisał(a):
Ja tak w kilku systemach robiłem. Działa, pozwala wyświetlić komunikat typu: użytkownik z edytuje rekord itd.
To co opisuje @Schadoow też jest jakimś podejściem, ale osobiście nie preferuję wkurzania użytkowników.
No zawsze można ich nie wkurzać, po prostu nie zapisać zmian z przestarzałej kopii. Albo odwrotnie - ostatni wygrywa.
Tak czy siak, to nie ma sensu zadawanie tego pytania na tym forum, bo to nie jest kwestia techniczna tylko biznesowa.
@somekind: to jest głównie kwestia biznesowa, ale OP chyba dostał właśnie takie zadanie. Rozważając za i przeciw w jakiejś dyskusji warto zawsze wspomnieć, że wtedy jeden użytkownik może być niezadowolony. Ot cała idea tego mojego postu.
Nasz najlepszy w Polsce ERP jest projektowany na postawie opinii z forów internetowych
prawda, że tego jeszcze w marketingu nie było?