Ahojte,
robim taky jednoduchsi CMS a narazil som na problem:

Po lognuti do CMS mam stranku s uploadom fotiek do galerie, pri uspesnom uploade sa zaznamenaju zmeny do DB.
Avsak jednotlive galerie sa daju editovat a zmazat.

Moj problem je ten, ze mozem editovat galeriu:
(1) uploadujem fotky
(2) zatial v novom tabe dam zmazat galeriu
Kedze upload nieco trva, zmazanie prebehne hned a po dokonceni uploadu (1) uz nemam kam zapisat zmeny, nakolko uz zaznam je zmazany (2).

Ako ste riesili / by ste riesili dany problem?
Nieco mi napada, no radsej si necham poradit od profikov, dakujem.

Staci ti odchytit chybu ktoru ti vypise SQL, zapis si ju do error logu a pouzivatelovi napis ze sa vyskytla chyba a reloadni stranku.

Potom na klasickej stranke kde moze uploadovat si myslim ze mas nejaky check ci album existuje alebo nie.


Pride mi to ako lepsia moznost nez kontrolovat pri kazdom uploade ci album existuje.

Check mam, ale po uploade sa kazda fotka upravi, cize na zaciatku album existuje, no po par fotkach uz nemusi a kontrolu nerobim po kazdej fotke.

Mna napadlo oznacit DB riadok "flagom" locked = 1.
Nasledne by skript vypisal, ze iny proces prebieha v pripade, ze stale bol flag locked = 1.
Nie je to dobre riesenie?

Nieje, takto mozes bloknut aj inych ludi.

To ze sa upravuje fotka je jedno, pokial si ju uz raz ulozil do DB. To by som skor riesil skriptom ktory by prehladaval zlozku s fotkami a mazal vsetky ktore niesu v nejakom albume. Takto by si este aj usetril miesto na disku.

Bolo by fjan keby si to dokazal lepsie priblizit, co tam robis a hlavne ako, nech mam predstavu co by bolo idealne.

Neblokoval by som inych, lebo kazdy ma vlastne albumy.
V 1 riadku DB mam JSON data o suboroch, cize komplet album s fotkami je 1 zaznam v DB.
Skript nacita tieto data - existujuce subory, nasledne prida nove fotky z uploadu a tento array so vsetkymi fotkami ulozi.
Cize problem je vtedy, ked sa pridavaju nove fotky, no zatial sa album (s povodnymi fotkami) zmaze.
JSON obsahuje aj nazvy starych fotiek, ktore uz neexistuju a nemoze ani update DB spravit, lebo ID zaznamu sa uz v DB nenachadza.

Tak to je tym ze to mas takto stupidne spravene, ze ukladas fotky do DB ako jediny zaznam.

Omnoho jednoduchsie (a lepsie) je spravit si tabulku kde budu albumy a potom druhu tabulku, kde budu fotky priradene albumom cez ID albumu pri fotke. Bude to rovnako rychle (a s indexom na album_id pri vela zaznamoch niekedy aj rychlejsie) a vyhnes sa prave takymto problemom.

Dakujem za radu a tip, ale predstav si situaciu:
Tabulka ALBUM ma ID 1 a NAZOV "moja dovolenka 2015",
tabulka FOTO ma ID 1, ALBUM 1, NAZOV test1.jpg,
ID 2, ALBUM 1, NAZOV test2.jpg

Obe fotky teda patria pod rovnaky album.
Dam upload fotiek k albumu 1, no hned kliknem na zmazanie albumu.
Kym sa fotky spracuju (upload je hotovy, skript bezi), zmazu sa fotky, zaznamy v tabulke FOTO s hodnotou ALBUM 1 a aj zaznam z tabulky ALBUM, kde id je 1.
Pridaju sa teda nove zaznamy do FOTO, avsak nebudu s nicim prepojene, nakolko zaznam v ALBUM neexistuje.

Cize podla mna taketo dva skripty (upload a mazanie) nemozu naraz bezat nad jednym albumom, lebo inac budu problemy vzdy.

Preto existuje niečo, čo sa nazýva ACID vlastnosti. Ten zápis musíš spraviť v rámci jednej transakcie.

Jediný problém by som videl v dĺžke uploadu ak je viac obrázkov, pri ktorom by mohlo niečo zostať zamknuté príliš dlho.
To by sa mohlo dať ošetriť cez správny isolation level.

Kludne pouzi Foreign keys nastavene vo foto tabulke na album. Ak album s takym ID neexistuje, vyhodi to chybu pri zapise, ktoru jednoducho odchytis a informujes pouzivatela.

94jakub napísal:Preto existuje niečo, čo sa nazýva ACID vlastnosti. Ten zápis musíš spraviť v rámci jednej transakcie.

Jediný problém by som videl v dĺžke uploadu ak je viac obrázkov, pri ktorom by mohlo niečo zostať zamknuté príliš dlho.
To by sa mohlo dať ošetriť cez správny isolation level.

ACID mam vyrieseny, nakolko teraz sa vsetko zapisuje do 1 zaznamu.
Problem je existencia suborov, ktore zatial mozu byt zmazane a ACID riesi iba DB.
Ak by som to zamkol cez moje navrhovane riesenie (locked=1), zamknuty by bol iba 1 zaznam (album) a tak by to aj malo byt.
Zamkynat celu tabulku je nezmysel, nakolko aj ini mozu v dany okamih pracovat s albumami.

Michaelo napísal:Kludne pouzi Foreign keys nastavene vo foto tabulke na album. Ak album s takym ID neexistuje, vyhodi to chybu pri zapise, ktoru jednoducho odchytis a informujes pouzivatela.

Aj to je riesenie, ale musel by som zaznamenavat vsetky zmeny na disku (vytvorene fotky) a nasledne ich zmazat.

Stale by som rad vedel vas nazor k mojmu navrhu riesit to cez flag "locked = 1" - co je na tom zle a nevhodne?

Vsetko?


A co tak najprv uploadnut vsetky fotky, spravit zmeny a az tak ich zapisat do DB? Co za zmeny tam robis? Imagick, alebo? Lebo ten netrva az tak dlho (ak ano, robis nieco zle) a kludne by si mohol dat zapisat fotky do DB az po tom, co sa upravili... Ale stale by som to neukladal ako jediny zaznam.

Preco by si to mal zaznamenavat? Ak ti vyhodi chybu ze album neexistuje, stale mas nazvy fotiek ktore si chcel do DB zapisat, tak ich rovno zmazes.

Co "vsetko" konkretne je zle?

Cez Imagine (vyuziva Imagick) sa mi vytvaraju nahlady a tiez zmensene fotky, ale spracovat 10MP fotku trva par sekund.
Ukladanim ako jeden zaznam som chcel znizit pocet SQL dotazov na minimum, no mozem to prerobit.

A co tak flag deleted? Pri zmazani nastavis na true a subezny upload prebehne bez chyby (kedze bude existovat zaznam s flagom deleted=true) ked tak mozes spravit warning ze subor bol zmazany ak je nastaveny deleted. + pripadne mozes este delete na zmazane fotky > 30 dni ak by tabulka narastla. alebo aj ui pre superUsera ktory moze zrusit zmazanie:D
A urcite albumy a fotky do 2 tabuliek.

Boccaccio napísal: Stale by som rad vedel vas nazor k mojmu navrhu riesit to cez flag "locked = 1" - co je na tom zle a nevhodne?

napríklad to, že musíš ten záznam potom aj odomknúť. A to je kritické, lebo ak sa to nepodarí, tak ostane neprístupný navždy. A moc si ani neviem predstaviť, kedy ho chceš odomykať. Keď dobehne upload nejako ajaxom? A čo ak nedobehne (zamrzne browser, reštartuje ho...)

to že niekto zmaže album počas uploadu je výnimka. Treba ju odchytiť a vypísať chybu pri uploade (a následne upratať, ale to už môže byť offline proces). Nemá zmysel bojovať proti užívateľovi a snažiť sa zakázať mu všetky možné varianty ako by ti mohol rozhodiť systém, lebo určite na všetky neprídeš.

a samozrejme celý návrh máš asi zle, ak máš album aj fotky v tej istej tabuľke.

Dakujem vsetkym, upravim si to do 2 tabuliek a pripadne sa ozvem.

Zistil som vsak druhy problem - mam nastaveny limit 10 fotiek na album.
Skript zisti pocet zaznamov (pocitam uz s novym riesenim 2 tabuliek) cez COUNT(*), vygeneruje fotku z uploadu a zapise zaznam do DB.
Ako zabranim pripadu, ze sa spustia 2 taketo skripty, obe zistia, ze zaznamov je 9, vygeneruju fotku a ulozia zaznamy.
Zaznamov uz bude 11, teda prekroci sa limit.

použi transakciu alebo zamykanie. Ale pravdepodobnosť že sa také niečo stane je mizivá

audiotrack napísal:použi transakciu alebo zamykanie. Ale pravdepodobnosť že sa také niečo stane je mizivá

zamykanie by to vyriesilo, transakcia asi nie - resp. ako by mala vyzerat takto transakcia?
Lebo COMMIT nastane az po spocitani cez COUNT a medzi tymito operaciami moze pribudnut novy zaznam a count uz nebude mat relevantny udaj (je to mala pravdepodobnost, ale je)

commit bude vtedy, keď ho zavoláš. Daj si select spolu s insertom do transakcie.

Myslis to takto?
edit: pridal som usleep(3000000); medzi count() a insert(), spustil naraz a mam 11 zaznamov

skoro, ale ten insert by sa mal robiť iba ak je $count <= 10. A podmienka či sa commitne alebo rollbackne bude na základe toho či zbehol insert