Administrace komentářů

U mě problém není.

Je - ale nev algoritmu. Celá tadle subdebata se vede, protože si netušil, že Mysql umí multihodnotové IN, nevěděl jsi, jak implementovat verzování pomocí jedný sdílený sekvence:

... Jak se změní verze?

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

No to bude báječné, takže kdokoli udělá nějakou změnu, všem ostatním tím způsobí konflikt.

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.

To, že se Tvůj algoritmus bez verzování chová špatně jsem doložil na příkladech, že je nejsi schopen pochopit nebo i vymyslet sám, můj problém není (omlouvám se za sarkasmus, ale to fakt už nejde).

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, s tím se holt polemizovat nedá. Holt jen počítej, že když takovou aplikaci napíšeš, tak Ti ten mistr dá přes hubu, až mu to bude např. blbě počítat přesčasy.

Co ty písmenka znamenají? Umíš číst? Vždyť to v minulym postu píšu. Prosím už po desáté, alespoň zkus číst co jsem napsal. Tak znova: Můžeš si pod každým písmenkem např. představit datum, kdy byl daný užívák v práci. 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. 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. Pokud se tedy aplikace v těchto případech chová odlišně, tak budou uživatelé na aplikaci nadávat. A Tvůj algoritmus se právě (mj.) v těchto případech (bez verzování, viz výš) nekonzistentně chová.

PS: 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.

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í Přitom B provedl akci později a tak by tam měl zůstat záznam B. A třeba zrovna toto neodstraní ani Tebou navržené verzování.

PPS: 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).