Administrace komentářů

Celá tadle subdebata se vede, protože si netušil, že Mysql umí multihodnotové IN

Zda to umí nebo neumí je nepodstatný implementační detail. Když to nemá popsané v dokumentaci operátoru IN, je celkem logické myslet si, že to neumí.

nevěděl jsi, jak implementovat verzování pomocí jedný sdílený sekvence

Nevěděl jsem, jak to udělat funkčně. Vaše nefunkční řešení mne nezajímá.

a tvrdil jsi, že to verzování bude nějak působit nějaké konflikty.

Standardní verzování jednotlivých řádků, které jsem použil, problémy způsobovat nebude. Problémy bude způsobovat vaše neverzování.

Jestli to tedy už netvrdíš (co takhle uznat omyl?), tak ok, tak je jasné, že verzování jde dělat v obou algoritmech(v mém přístupu není problém zkontrolovat, že všechny mazané mají správnou verzi). Jelikož i Tvůj algoritmus bez verzování se nechová v multiuser prostředí dobře (viz dál) a v obou jde verzování snadno implementovat, pak nemá smysl se o verzování bavit. Proto ho také můj algoritmus neobsahoval - narozdíl od Tebe se snažím soustředit na princip.

O čem to píšete? Já jsem navrhl nějaký algoritmus s verzováním, který funguje. Vy jste navrhl algoritmus bez verzování, který nefunguje. Pak jste ho různě měnil a vycházely vám z toho nefunkční verze, až když jste jej konečně změnil na ten, který jsem já popsal hned na začátku, začalo vám to fungovat.

To že tvrdíš, že když mistr i jeho zástupce napíšou dělníkovi najednou presenci, tak že je správně, že ji má dvakrát

To se v mém algoritmu neděje. To jen ten váš vyrábí v databázi hlouposti.

Můžeš si pod každým písmenkem např. představit datum, kdy byl daný užívák v práci.

V tom případě si tam nejdříve doplňte primární klíče, ať se máme o čem bavit.

A ano, normální člověk v životě používá většinou pro identifikaci něco jiného, než primární klíč - u data např. právě to datum.

Normální člověk ovšem nemá problém poznat, co je jeden objekt, a co jiný, a je si jist tím, zda jsou to dva objekty nebo jeden. Dokáže ty objekty identifikovat - a primární klíč je jen způsob, jak tu identifikaci vyjádřit v databázi.

To, že záznam nějakej PK má, uživatele vůbec netrápí a právě proto je CHYBA očekávat, že bude rozlišovat mezi přepsáním data a smazáním + vytvořením nového: protože tyto operace se liší právě pouze tím, jaké má výsledný záznam PK.

Chyba to není, každý normální člověk takhle přemýšlí. I malé dítě ve školce pozná rozdíl v tom, jestli mu jedno jablko vezmete a dáte mu místo něj jiné, nebo jestli do jednoho jablka kousnete.

A Tvůj algoritmus se právě (mj.) v těchto případech (bez verzování, viz výš) nekonzistentně chová.

Můj algoritmus ale verzování má.

Tvůj výkřik s vyjmenováním padesáti programů, kdy každej má multiuser konkurenci vyřešenou lépe či hůře různými algoritmy (často i pštrosem) pak komentovat vůbec nebudu, nevím, co tím chtěl básník říci.

To je dobře, že to nekomentujete, protože já jsem nic takového nenapsal. Pocit, že někdo v této diskusi neumí číst, máte správný. Bohužel vás ale musím zklamat, že tím dotyčným jste vy. Zkuste si přečíst ještě jednou, na co jsem reagoval.

A pokud Ti nestačí soupis chyb, tak tady máš další: A nějaký záznam smaže a potom B ten samý záznam (browser si otevřel před potvrzením transakce A) změní, tak ten záznam stejně zmizí

Nezmizí. B bude upozorněn, že někdo mezi tím změnil data, a dostane na výběr, jak konflikt vyřešit.

Btw. - ono ani s verzováním z PRINCIPU nelze problém současné editace vyřešit. Jestli nechápeš proč, tak se zamysli, proč v databázích existuje izolace transakcí SERIALIZABLE, která právě tento problém řeší, a proč transakce na této úrovni izolace nejsou zaručeně proveditelné (tzn. mohou být zaříznuté, že nejdou serializovat).

Od někoho, kdo do teď nepochopil, jak optimistické zamykání s verzováním řádků funguje, to je opravdu vtipný komentář. Až to pochopíte, pochopíte taky, proč verzování řádků zabrání skrytému ztrácení změn.