Hlúpy formulár - ako naň

[Stanislav Hruška]

Myslel jsi na editaci stejneho zaznamu vicero uzivateli?

Myslel, ale ešte som to nijako neriešil. Tomu sa chcem venovať až dosiahnem cieľ.
Ja problematiku viacnásobného prístupu neovládam. Musím si ju najprv naštudovať.

Mám dve teoretické možnosti:
  1) riešiť to tak ako sa to má.
  2) k SVB môže v jednom čase pristupovať (pracovať s ním) len jediný užívateľ. Ale tomu nie som naklonený.

A prečo ponúkaš komplikované riešenia   = pomocná tabuľka...

[96972]

Myslel jsi na editaci stejneho zaznamu vicero uzivateli?

Myslel, ale ešte som to nijako neriešil.

Zachovani veskerych editaci stejneho zaznamu se da bezpecne vyresit verzovanim (tj. ze se uchova kazda modifikace radku napr. s loginem autora a casem zmeny). Coz ma zjevnou nevyhodu v objemu dat. Na druhou stranu odpadnou snad za cenu disku (nebo diskoveho pole) dohady o tom kdo a kdy jaka data upravil. To samozrejme neni vsemocne.

Typicky scenar konkurencni editace muze vypadat takto:

Uzivatel zapocne editaci (napr. otevrenim modalniho okna), aplikace zamkne zaznam (je jedno jestli DBMS zamkem nebo jen virtualne separatni tabulkou) a ten debil odejde treba na obed (nebo bude zodpovedny, avsak jeho mene inteligentni kolega mu znenadani rozseka pocitac bouracim kladivem). O par dveri stranou se pak bude vyhradne atraktivni sekretarka snazit upravit ten samy zaznam. Kdyz z aplikace vyskoci dialog informujic o zakazu operace kvuli editaci zapocate kolegou, rozhodne se zavolat svemu vlidnemu firemnimu IT administratorovi ktery ji s ochotou (diky jeji atraktivnosti) zaznam bez dalsiho badani odemkne. Jenze co v takovem pripade delat s aplikaci?

Zaznam byl zamcen zapocetim editace, to je vse co databaze vi. Uz ale nemuze tusit zda takova editace kdy skonci (nasyceny kolega by to zvladnout mohl, pocitac upraveny bouracim kladivem uz nejspis ne). Muze tim dojit k deadlocku zaznamu.

Da se vymyslet spousta zpusobu jak takovou situaci z pohledu UI vyresit. Bude vsak vyhodnejsi moznost kdy se data neprepisi, ale vytvori se nova verze zaznamu, cimz ani slicna sekretarka neprijde o svou upravu v pripade navratu hodujiciho kolegy.

[pf1957]

Da se vymyslet spousta zpusobu jak takovou situaci z pohledu UI vyresit. Bude vsak vyhodnejsi moznost kdy se data neprepisi, ale vytvori se nova verze zaznamu,

Ale tim prece nic nevyresis - stejne bude muset nekdo rozhodnout o tom, ktera z tech verzi je platna, protoze vetsinou nemuzou existovat v jeden cas ruzne varianty tehoz,
takze do aplikace budes muset navic implementovat funkcionalitu pro sefa, aby mohl vyresit kolize verzi.

Ja bych to resil vuci BFU ofenzivne tj. pomoci OCC (Optimistic Currency Control) zahrnutim detekce konfliktu a vyfuckovanim zmen pri konfliktu tj. do DB modelu bych pridal pole s verzi radku (rada RDBMS neco takoveho podporuje, ja se s tim potkal u DB/2 a MSSQL), pri fetch si ho nacetl a v prikazu, ktery zkousi menit data bych do where klauzule pridal podminku na shodu verze radku mezi fetchnutou hodnotou a skutecnou hodnotou v DB v okamziku modifikujici transakce. A v pripade rozdilu bych nedovolil DB modifikovat a zobrazil BFU, ze zatim co byl na obede, uz to nekdo zmenil a at si to resi. Kdyz bych na nej chtel byt hodne friendly, tak bych mu pres mechnismus validace zobrazil, co se zmenilo.

Mam dojem, ze Delphi obsahuje nekde na urovni  Data Snap nejakou podporu pro OCC, ktera nejak obhospodaruje stary/novy zaznam a nejakou podporu pro reseni , ale nikdy jsem s tim nic nedelal.

[96976]

[quote  link=topic=15806.msg96972#msg96972 date=1505424250]
Da se vymyslet spousta zpusobu jak takovou situaci z pohledu UI vyresit. Bude vsak vyhodnejsi moznost kdy se data neprepisi, ale vytvori se nova verze zaznamu,

Ale tim prece nic nevyresis - stejne bude muset nekdo rozhodnout o tom, ktera z tech verzi je platna, protoze vetsinou nemuzou existovat v jeden cas ruzne varianty tehoz,
takze do aplikace budes muset navic implementovat funkcionalitu pro sefa, aby mohl vyresit kolize verzi.
[/quote]

To ano. Zbavis se tim ale volani zakaznika "ono to nefunguje, ztratila se nam data" Navic se muzes podivat i do historie.
Hloupost nekterych uzivatelu prekracuje limit chapani vesmiru jako celku a i pres vselijaka varovani jsou schopni vse bezhlave odklikat a nasledne reklamovat. Za cenu disku bych spis volil variantu verzovani.

On i tento projekt de-facto verzovani uz pouziva. Kdyz se vymeni najemnici, ve vazebnich tabulkach pribude zaznam o zmene s tim ze se muzu zpetne podivat kdo v byte v danou dobu bydlel.

[pf1957]

Hloupost nekterych uzivatelu prekracuje limit chapani vesmiru jako celku a i pres vselijaka varovani jsou schopni vse bezhlave odklikat a nasledne reklamovat.

Kdyz si to plati, at reklamuji, ne?

[Stanislav Hruška]

To Radek

Vid napr. velmi pekny Radkov clanok http://delphi.cz/post/Jak-jsem-modernizoval-UI-a-UX.aspx.

Prosím Ťa, akú veľkosť ikôn si použil v bočnom strome. Na 16 x 16 to nevyzerá.
Ďakujem.

[Daniel_Andrascik]

Celkom podnetna debata pani. Osetrit bezpecnoct prace s datami na urovni db je samozrejmost a aj som sa vcelku zamyslel nad vasimi odporucaniami.

Ale ja som v kontexte tohto vlakna narazal aj na fakt ze na komplikovanom formulary kde sa mozu motat rozne pohlady a zavislosti je mozne data stratit alebo skor hlavne pomotat uz na hornej urovni aplikacnej logiky vramci formulara. Ale to som spominal len tak na okraj, ako dalsie potencionalne riziko komplikovanych formularov. Podarilo sa mi to uz aj u jednoduchych formularov. Myslim ze kazdy kto vyvyjate UI ste raz alebo viackrat boli velmi prekvapeni ake nemyslitelne kombinacie dokazu uzivatelia poklikat na takom formulari, co by sa vam ako developerovy ani vo sne nesnivalo. A napriek velkej snahe vsetko mozne i nemozne osetrit sa predsa len moze stat ze nejaka zamotana situacia ostane neosetrena. A u prekomplikovaneho formulara si clovek moze byt takmer isty ze tam bude mat zasite nejake tie neosetrene nebezpecne kombinacie akcii a reakcii... 

[96984]

Ale ja som v kontexte tohto vlakna narazal aj na fakt ze na komplikovanom formulary kde sa mozu motat rozne pohlady a zavislosti je mozne data stratit alebo skor hlavne pomotat uz na hornej urovni aplikacnej logiky vramci formulara.

Muzu se zeptat na konkretni priklad? Za predpokladu, kdy:

- model umi vazby (dokaze napr. kaskadove mazat zaznamy)
- model ma i moznost manualniho linkovani udalosti a stavu "mimovazebnich" modelu (muzu tak napr. zamykat i "nesouvisejici" model)
- pohledy na model samozrejme obsahuji "jen" odkazy na jeho zaznamy
- zaznam modelu je editovan vstupem pres re-entrantni zamek (BeginEdit) s moznosti jej vypnout a posilat uzivatele do haje s tim ze se uz nekde v prave spustene aplikaci presne ten samy zaznam snazi editovat
- vse je transakcni na urovni modelu, ne pohledu; dokud se nerekne modelu "commit", jsou radky jen ve stavech "upraven", "smazan" atd. (viz. DataRowState)

Ad verzovani:

Nejhorsi je pouzit verzovani jen nekde a uzivateli nabidnout pohled do minulosti. A nemusi jit zrovna o konkurencni pristup. Napr. uchovas verze vazeb byt/najemnik a najemnika nechas bez verzovani. Hledej potom podle jmena Annu Blazkovou ze ktere se presitim stal se vsim vsudy Adam Blazek Neni to sice vhodny priklad, ale pro vysvetleni principu staci