Ahojte,
potreboval by som radu:

V tabulke TABLE potrebujem maximalne 5 zaznamov, ktore maju user = "JOZKO".
Skript jozko.php prida novy zaznam sposobom:

1. zistim pocet zaznamov pre user = "JOZKO"
2. ak je pocet mensi ako 5, insertne novy zaznam
3. opat skontroluje pocet zaznamov pre user = "JOZKO", ak je zaznamov viac ako 5, rollbackne insert, v opacnom pripade da commit

Uz v minulosti niekto radil, ze kontrola (3.) je zbytocna, ze medzi (1.) "zistenie poctu" a (2.) "insertnutie" nie je priestor pre dalsie spustenie skriptu, no nie je to pravda.
Ak totiz medzi to (1. a 2.) vlozim sleep(10) a zatial spustim skript opat, oba skripty maju pociatocny pocet zaznamov a obe tym padom insertnu.

Je moj napad dobry, pripadne ako sa taketo veci riesia?
Dakujem.

V praxi som sa sice vzdy stretol s odporom voci triggerom ale tu by sa to celkom hodilo.
Pripadne mozes zamknut celu tabulku (optimistic locking by v tvojom pripade nefungoval).

Ja by som si napisal na tu tabulku trigger...

//autoeditácia príspevku (26 Máj 2016, 12:41)
ako citam tak trigger ti nieco ako cancel insert neponuka

takze ti ostava lock alebo tu logiku osetrit nejako inak... preco vlastne potrebujes obmedzovat pocet zaznamov v tabulke pre usera?

ak trigger, tak to rovno mozem pouzit moj napad

nuz a potrebujem obmedzit system, aby ludia nerobili blbosti a nenapisali bota, co by naplnil databazu kravinami

takze user insertne 5 veci a potom uz nic? ako chapem ak by si mu mazal najstarsie veci ale podla tvojho navrhu vlozi 5 riadkov a potom uz nic... nechces mu radsej pri kazdom vlozeni mazat posledny zaznam?

nie, musi mat obmedzenie - cislo 5 som dal ako priklad, realne to bude vysoke cislo, ktore bezny user nedosiahne
riesim skor ochranu proti botom

Ak je to len preto, tak žiadnu dodatočnú kontrolu nemusíš ani riešiť. Vloží sa piaty záznam a pred vložením šiesteho sa zistí, že už je ich tam päť. A keď aj príde k nejakému súbehu, tak sa to nezistí pri šiestom, ale pri siedmom, alebo ôsmom. Raz sa to proste zastaví a bude to max v jednotkách záznamov.

Dobra odpoved, dakujem.
A keby som do buducna chcel mat presne maximalne 5 zaznamov, tak co? Alebo inac sa opytam - je moj napad s transakciou blby?

Transakcia v tomto veľmi nepomôže kvôli tomu I v ACID. Ja by som bol asi za exclusive lock. Dalo by sa určite vymyslieť aj nejaké explicitné zamykanie, ale to už by asi bolo zbytočne zložité.

Boccaccio napísal: keby som do buducna chcel mat presne maximalne 5 zaznamov, tak co?

Co takto?
Insertnes zaznam, zistis pocet a vsteky zvysne zmazes ?
Pouzivatel moze mat viac zaznamou ale len na okamih.

harrison314 napísal: Co takto?
Insertnes zaznam, zistis pocet a vsteky zvysne zmazes ?
Pouzivatel moze mat viac zaznamou ale len na okamih.

nie je to moj napad? rozdiel je iba v tom, ze ty by si mazal a ja by som dal rollback (neulozenie)

Mazal by som vsteky zaznamy ktore su navyse, nie len posledny.

harrison314 napísal:Mazal by som vsteky zaznamy ktore su navyse, nie len posledny.

Rozumiem, ale vysledok by bol rovnaky, ani u teba, ani u mna by nebolo viac ako 5 zaznamov.

Rozdiel je v tom, že kým harrisonov delete zamkne tabulku (alebo riadky? nie som istý) pre všetky selecty, tvoja transakcia nie. Atomicita je totiž na úrovni jednej transakcie, nie celej databázy (ako si sa už presvedčil sám v prvom príspevku). Takže kým ty v transakcii skontroluješ súčasný stav a zahájiš commit/rollback, už môže byť všetko inak.
Príklad (veľmi nepravdepodobný, ale možný): Spustím takýchto insertov 10 naraz. Všetky sa spustia, insertnú (pretože nájdu 0 záznamov) a príde k tretej kontrole. Všetky zistia, že je tam stále 0 záznamov (pretože neprebehol ani jeden commit) a tak príde 10x commit.
(toto je default chovanie MySQL innodb, viď isolation levels, ak by si prepol na READ UNCOMMITED, tak by to asi fungovalo)

Ano. Presne ako pises. Ja mam READ UNCOMMITED, takze mi to funguje a DB nepotrebuje dalsie locky, cim vsetky ine procesy zbehnu bez cakania (na unlock).
Je to takto prosim OK? Aj DB ma default level READ UNCOMMITED, takze to nebude len tak...

Rozdiel medzi tvojim a mojim, je pri pade aplikacie, a aj v tom co napisal BX.
Mazanie az po vlozeni, ti osetri, aj ine chybove stavy.

Ale preco to nespravit normalne? Pri vytvoreni (registracii) pouzivatela prosto vytvoris 5 zaznamov v tabulke, a budu mat flag, ze su nekativne, pouzivatel nebude moct dalsie zaznami vyvrat, ale len updatovat existujuce.

Myslím, že by to nebolo veľmi vhodné riešenie, nakoľko sa nejedná na ozajstné číslo 5:

nie, musi mat obmedzenie - cislo 5 som dal ako priklad, realne to bude vysoke cislo, ktore bezny user nedosiahne

Hej. To je blbost, lebo sa jedna o maximum, ktory 99.9% uzivatelov nevyuzije.

//autoeditácia príspevku (28 Máj 2016, 0:42)
Ak mam transakciu, dam insert a skor ako sa vykona commit spadne db (server), ten insert zbehne alebo sa neulozi?

//autoeditácia príspevku (28 Máj 2016, 18:20)
Neulozi sa, cize vsetko funguje skvelo aj s mojim napadom. Asi to tak teda spravim, ak niekto nema lepsi napad.