nastaveni prav k tabulkam

[Petr.Vileta]

Prosim o
1) vytvoreni tabulky evidence_log

Kód: Vybrat vše

USE `pirati`;
CREATE TABLE `evidence_log` (
  `id` bigint(14) unsigned NOT NULL AUTO_INCREMENT,
  `datum_cas` timestamp NULL DEFAULT NULL,
  `provedl` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `pro_koho` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `popis` text COLLATE utf8_czech_ci NOT NULL,
  PRIMARY KEY (`id`),
  KEY `datum_cas` (`datum_cas`),
  KEY `kdo` (`provedl`,`datum_cas`),
  KEY `pro_koho` (`pro_koho`,`datum_cas`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci COMMENT='logovani vsech zmen provedenych pres Evidenci';

2) nastaveni prava LOCK k dale uvedenym tabulkam pro uzivatele 'vedouciao'@'localhost'

evidence_clenstvi
evidence_dokumenty
evidence_prava
evidence_setup
evidence_log
phpbb_user_group
phpbb_groups
phpbb_profile_fields
phpbb_profile_fields_data
phpbb_users

[Lukas.Novy]

Opět se ptám, na co LOCK?

[Petr.Vileta]

Ale porad na to same jen jsem jednu tabulku zapomel, tak pro jistotu uvadim vsechny. Tabulky zacinajici "evidence_" jsou moje a s forem nesouvisi.

Jde o to, ze nevim, v jakem poradi se meni data pri jakekoliv akci v administraci fora (pres phpbb admin panel) ale vim, jake tabulky se nesmi menit, pokud provadim nejakou akci se svymi tabulkami. Takze je vsechny zamknu, provedu akci a odemknu. Zdrzeni pro admina je maximalne 3 sekundy a to mu php v zadnem pripade neskonci na timeout.

[Lukas.Novy]

3 sekundy je strasne moc. Navic ten LOCK ti nepomuze, je stejna pravdepodobnost, ze si prectes data bez locku, ktery nejsou konzistentni, jako ze to lockes v okamziku kdy konzistentni nejsou a prectes je nekonzistente stejne. Na phpbb_ tabulky LOCK proste nedame a hotovo.

[Petr.Vileta]

3 sekundy je strasne moc. Navic ten LOCK ti nepomuze, je stejna pravdepodobnost, ze si prectes data bez locku, ktery nejsou konzistentni, jako ze to lockes v okamziku kdy konzistentni nejsou a prectes je nekonzistente stejne. Na phpbb_ tabulky LOCK proste nedame a hotovo.

No za prve tam ten lock uz dal Petr Stehlik a za druhe mi tedy preved phpbb do InnoDB a budu pouzivat transakce a kdyz se nezdari, tak ROLLBACK.

Me totiz desne se*ou tihle matlalove, kteri pouzivaji desitky tabulek vzajemne provazanych a delaji to v MyISAM bez locku a jakekoliv zpetne kontroly a jeste tam pusti neomezeny pocet administratoru. Tohle vazne neni dobry zpusob programovani. Kdyz delam program pro vice nez jednoho uzivatele, tak musim automaticky pocitat s tim, ze mohou pracovat vsichni soucasne a v zadnem pripade to nesmi menit data stylem "posledni vyhrava"

Prosim tedy o informaci od vedouciho TO, jestli LOCK mohu pouzivat.

[Petr Stehlik]

3 sekundy je strasne moc. Navic ten LOCK ti nepomuze, je stejna pravdepodobnost, ze si prectes data bez locku, ktery nejsou konzistentni, jako ze to lockes v okamziku kdy konzistentni nejsou a prectes je nekonzistente stejne. Na phpbb_ tabulky LOCK proste nedame a hotovo.

to zní rozumně, jako že ten LOCK vlastně k ničemu není.

[Petr.Vileta]

3 sekundy je strasne moc. Navic ten LOCK ti nepomuze, je stejna pravdepodobnost, ze si prectes data bez locku, ktery nejsou konzistentni, jako ze to lockes v okamziku kdy konzistentni nejsou a prectes je nekonzistente stejne. Na phpbb_ tabulky LOCK proste nedame a hotovo.

to zní rozumně, jako že ten LOCK vlastně k ničemu není.

Pokud provadim jednu zmenu, pak budiz, nemusim LOCK pouzivat. Jenze ten skript pro cron kontroluje vsechny cleny a jejich clenstvi ve vsech skupinach. Pokud by byla data konzistentni a pred spustenim skriptu by probehlo behem dne treba 10 zmen, pak musim zapsat 10 nebo vice zaznamu do "mych" tabulek. Ale kdyz v dobe behu skriptu bude pracovat jeden admin, mohou byt data nekonzistentni pro 1 clena, kdyz budou pracovat dva admini, mohou byt nekonzistentni uz pro 2 cleny atd. A adminu mame docela dost. Kazdy vedouci kraje je admin sveho kraje, vedouci komise nebo odboru je admin sve komise nebo odboru. Takze v nejhorsim pripade muze pracovat soucasne minimalne 15 (kraje + sef AO) adminu.

Timeout databaze je myslim 30 sekund, timeout php pravdepodobne take. Takze moje 3 sekundy by fakt nemely nikomu vadit. Navic ja to zamykam proti zapisu, takze na cteni je to normalne pristupne.

Prosim tedy o jasne stanovisko, zaridim se podle toho.

[Lukas.Novy]

Chces tim naznacit, ze behem 3 sekundoveho intervalu ve 2 hodiny rano bude 15 adminu zaroven upravovat nejakeho uzivatele?

Pokud si prectes nejdriv tabulku uzivatelu a pak podle id uzivatele selektujes z ostatnich tabulek, tak opravdu jedina vec, co se ti muze stat je, ze v ostatnich tabulkach nebudou zadne zaznamy a to v pripade, ze by admin v tom 3 sekundovem okne uzivatele smazal. Jako sorry, ale kvuli tomuhle zamykat tabulku byt jen pro cteni je nesmysl.

[Petr.Vileta]

Pracuji v podstate se tremi tabulkami fora, phpbb_groups, phpbb_users a phpbb_user_group. Z te prvni si nactu cisla skupin, ktere hodlam nejak kontrolovat a dam si to do pameti. Neni jich tolik, takze to moc pameti nesezere. Pak ale nasleduje to podstatne.

Vezmu jednu skupinu a v phpbb_user_group najdu jeji cleny. Pro kazdeho clena musim v "moji" tabulce najit, jestli je tam zapsany a jestli souhlasi nastaveni datumu, ze je predsedou/vedoucim, pripadne mistopredsedou. Kdyz tam zapsany neni, pridam si ho tam, kdyz tam zapsany je a cokoliv nesouhlasi, v jeho zaznamu doplnim aktualni datum jako datum konce platnosti zaznamu a udelam dalsi zaznam s aktualnim nastavenim stranickych funkci a nevyplnenym datem ukonceni platnosti zaznamu. Pak muze nastat jeste situace, ze je vsechno v poradku, pak nedelam nic. No a jdu na dalsiho clena skupiny a pak vezmu dalsi skupinu atd.

No a nakonec to vezmu obracene, tedy vezmu "moji" tabulku radku po radce a hledam, jestli clena konkretni skupiny je mozne nalezt v phpbb_user_group. Pokud ne, nekdo ho odtud smazal a ja opet musim v "moji" tabulce doplnit datum ukonceni platnosti zaznamu.

Mohl bych to sice nejprve nacist vsechno do pametovych promennych a pak pracovat s tim, ale phpbb_user_group ma pres 2500 records, phpbb_users pres 1500 a ja nerad pisu programy, kde se vsechno cpe do pameti. Takhle je delany Drupal a vis co to dela za problemy.

A pokud jde o ty soucasne pracujici adminy, no samozrejme, ze jich asi nebude pracovat 15 najednou a zrovna v 5 rano, ale ja jsem zvykly psat programy tak, ze nespoleham na "stesti", ze tohle nikdo nezmackne, nebo ze dva lidi nemohou ve stejne sekunde odeslat editaci stejneho zaznamu. Nekolik mych sitovych a internetovych programu me tak vyucilo, ze to mozne je, ze ted proste na nejake stesti a pravdepodobnost nespoleham a program musi pamatovat i na tu nejvetsi absurditu.

[Lukas.Novy]

To co si popsal nepotrebuje lock.