První verze nového Light-weight cms RScms (diskuse)

[mirec]

Pozor, chystáte se komentovat 23 dní starou diskusi.

Nezdá sa mi, že by táto diskusia mala až toľko no ale o to nejde...

Nechce sa mi čítať kód .. chcel by som sa spýtať v kocke ako sú riešené transakcie?

[stativ]

Pozor, chystáte se komentovat 23 dní starou diskusi.

To bude možná tím, že jsem tenhle blog měl uložený už delší dobu, akorát se mi ho nechtělo publikovat než budu mít všechny zkoušky za sebou. Pak bych akorát strávil spoustu času opravováním chyb místo učením se.

Nezdá sa mi, že by táto diskusia mala až toľko no ale o to nejde...

Nechce sa mi čítať kód .. chcel by som sa spýtať v kocke ako sú riešené transakcie?

Ještě to není úplně hotovo, ale v zásadě jde o to, že jakmile se zavolá fce startTransaction tak se veškeré dotazy na DB začnou ukládat do paměti. Po zavolání fce commitTransaction() se všechny dotazy začnou odesílat do databáze. Po provedení každého dotazu se kontroluje, jestli byl proveden úspěšně. Pokud ano, tak pokračuje. Pokud ne, tak vrátí všechno zpět.

Bohužel to mám zatím implementováno jen pro odesílání nových dat. Pro mazání a updaty se totiž bude muset ještě ukládat původní obsah. A až to bude hotové, tak by se to v případě, že se rollback nepovede mělo všechno uložit na disk, odkud by se pak dala transakce znovu provést.

Co se týče cizích klíčů, tak ty se řeší vytvořením speciální tabulky, která ukládá informace o tom, jak jsou tabulky propojené a na základě toho probíhá vkládání dat. Ukládání potom probíhá tak, že se nejdříve uloží tabulka, ze které se klíč bere. Pak se zpětně v databázi vyhledá hodnota klíče (protože klíč může být, a v mém případě většinou je, generovaný) a vloží se na správné místo do dotazu ukládajícího obsah druhé tabulky. Bohužel tohle není (a ani nemůže být stoprocentní), protože když budou dvě tabulky na sobě cirkulárně závislé, tak nebude možné rozhodnout, která se má uložit dřív.

[TanisCZ]

No, že bych se na to nevys... Takové práce a zbytečně. Sice mě tady lidi ukamenujou, ale přesně kvůli podobným případům jsem rád, že existuje něco jako MSSQL :)

 

Ale jinak držim palce, jsem zvědavej, jak to bude fungovat. 

[stativ]

Hlavní důvod je v tom, že už delší dobu používám free webhosting od ic.cz a tam mi jaksi transakční databázi nedají. A řekl bych, že takových lidí bude víc, tak proč si tu transakčnost nedodělat růčo. Navíc dělám to ze zábavy, tak proč neudělat něco, co možná nikdo jiný ani nemá Navíc samotný kód cms (tj všechno kromě src/db_connectors/mysql.php) se tak dost zjednodušil, protože nemusím tolik kontrolovat, jestli se všechno proběhlo správně.

[Luk]

Lepší je změnit hosting. Mořit se s emulací transakcí kvůli ušetření pár korun za pořádný hosting mi přijde jako blbost.

[stativ]

Nad tím jsem přemýšlel, ale pak jsem došel k tomu, že je to velmi zajímavý problém, který by stálo za to vyřešit

[Luk]

Zrovna licence je to, co je potřeba vyřešit před zveřejněním. Jinak se může snadno stát, že buď to nebude pod žádnou licencí (= použití je nelegální), nebo to spadne pod public domain (= každý si s tím může dělat, skoro co chce) - v závislosti na tom, podle jakého práva by se to posuzovalo.

[stativ]

OK, tak já rychle dočtu těch posledních pár licencí, nad kterými uvažuji a přidám to tam.

[stativ]

Tak licence jsem už přidal. Něco málo jsem dal pod BSD licencí, zbytek je pod GPL v3, možná to ale ještě změním. Ale lepší je se rozhodnout brzo a špatně s možností to změnit, než se nerozhodnout a pak koukat na důsledky, které jsi už napsal.

[Luk]

Ad TinyMCE - pokud se pracuje s tabulkami, docela se hodí přidat tlačítko na smazání tabulky (v defaultu není). Tabulky jdou sice mazat i jinak, leckdy ale docela slušně vzdorují (hlavně pokud v nich nic není).

[stativ]

Tohle se dá nakonfigurovat v samostatném souboru (viz DOCS/INSTALL). Zatím jsem žádnou konfiguraci neprováděl, takže je tam prostě default nastavení TinyMCE. Ale budu na to myslet, až budu dělat default nastavení TinyMCE pro tenhle systém, protože mít toolbar dole je docela na houby.

[Mrkva]

Takze... Mel bych jen dve pripominky - pri vyskytu chyby volat die("blablabla") neni nejstastnejsi napad. Zvlast, kdyz stejne hlaseni vypise vic funkci. Pozdejsi ladeni a hledani chyb bude nocni mura.
Druha vec se tyka tech "transakci" bez InnoDB. (v tech uvozovkach je to zamerne - nesplnuje to hned dve z charakteristik transakci - zachovani atomicity a konzistence. Copak se asi stane, kdyz se behem toho vaseho "commitu" nebo "rollbacku" server odporouci?

[stativ]

Takze... Mel bych jen dve pripominky - pri vyskytu chyby volat die("blablabla") neni nejstastnejsi napad. Zvlast, kdyz stejne hlaseni vypise vic funkci. Pozdejsi ladeni a hledani chyb bude nocni mura.

Já myslel, že jsem se většiny už zbavil, ještě to omrknu. Předtím jsem to měl opravdu všude, ale špatně se to používalo v administraci pro upozornění uživatele o chybě. Jinak díky za připomínku.

Druha vec se tyka tech "transakci" bez InnoDB. (v tech uvozovkach je to zamerne - nesplnuje to hned dve z charakteristik transakci - zachovani atomicity a konzistence. Copak se asi stane, kdyz se behem toho vaseho "commitu" nebo "rollbacku" server odporouci?

Z toho důvodu chci ještě dodělat to uložení na disk. Možná i nějaký výpis na obrazovku, když se nepovede ani to. Nejdřív ale chci dodělat chybějící fičury (ty s ! v todo). Ono udělat něco takového bez podpory databáze je noční můra. Zase na druhou stranu mám pohodlí s používáním cizích klíčů kdekoliv. A pro transakční databáze je implementace „konektoru“ (vlastní? název třídy, která se stará o propojení s DB pomocí přesně daného rozhraní) o to jednodušší.

[TanisCZ]

To uložení na disk? Jak se pak pozná, když teoreticky server se odporoučí v době "transakce" místo kde transakce zkončila a  uděla se požadovaný rollback?

Respektivě mohl by si mi akorát nastínit, jak by to mělo teoreticky fungovat?

A bude to umět i transakce úložných procedur? Tím myslím, že budu mít nějakou stored procedure a budu potřebovat nad ní provádět transakce?

[stativ]

To uložení na disk? Jak se pak pozná, když teoreticky server se odporoučí v době "transakce" místo kde transakce zkončila a  uděla se požadovaný rollback?

Respektivě mohl by si mi akorát nastínit, jak by to mělo teoreticky fungovat?

Ta „transakce“ je ukládána v RAM serveru, kde běží php (já vím, je to blbé řešení už jenom kvůli možnému zaplácnutí RAM když by dat bylo moc, ale s tím se jaksi u tohohle pidisystému nepočítá). Mimochodem, pokud spadne server, kde beží php, tak to bude sakra velký průser.

K tomu jak by to mělo (snad) fungovat. Transakce je ukládána v RAM jako několik polí ($putRecordTrans, $updateRecordTrans, $deleteRecordTrans), které obsahují parametry, se kterými byly volány příslušné fce (putRecord(), updateRecord() a deleteRecord()). Pokud by došlo k problému, uložil by se soubor s parametry pro všechna volání v dané transakci a někam na začátek by se uložilo číslo, v kolikátém volání došlo k problému. Pak by bylo možné identifikovat, co vrátit a co už ne. Navíc by byla možnost tam ty data dodatečně nacpat. Toť teorie, jaká bude praxe ještě nevím.

A bude to umět i transakce úložných procedur? Tím myslím, že budu mít nějakou stored procedure a budu potřebovat nad ní provádět transakce?

Tolik to zas promáklé nebude. Hlavní je aby to mělo funkčnost, kterou požaduji já, tj. alespoň podpora cizích klíčů.

[TanisCZ]

Zajímavé řešení.  Ta ramka bude hodně limitujicí, jak to bude vypadat, když se celá ram zaplní a systém začně swapovat? A co třeba když poběží několik transakcí na ráz?

Zase velkou výhodu vidím v tom, že díky tomuhle řešení hodně odlehčíš sql serveru.

Jsem k tomu spíše skeptický, ale je to zajímavý nápad a určitě si procvičíš programovní :) Takže ať to vyjde, ale dofám, že tohle nebude nikdo nasazovat na produkční řešení.

A ta podpora cizích klíčů bude taky zajímavá. :) 

[stativ]

Zajímavé řešení.  Ta ramka bude hodně limitujicí, jak to bude vypadat, když se celá ram zaplní a systém začně swapovat?

Nemám ponětí.

A co třeba když poběží několik transakcí na ráz?

Vidíš, to mně nenapadlo. Napadl mně jenom jiný přístup k DB a proto se databáze spolu se zavolánim startTransaction() uzamkne. Asi to vyřeším sekvenčním odesíláním transakcí nebo jednodušeji prostým zablokováním dalších transakcí. To by mělo být pár řádků v startTransaction(), v podstatě jenom kontrola, jestli není $transactionMode nastaveno na true.

Zase velkou výhodu vidím v tom, že díky tomuhle řešení hodně odlehčíš sql serveru.

Jsem k tomu spíše skeptický, ale je to zajímavý nápad a určitě si procvičíš programovní :)

To asi jo.

Takže ať to vyjde, ale dofám, že tohle nebude nikdo nasazovat na produkční řešení.

Takhle vysoko ani nemířím. Budu rád když si to někdo třeba použije na svoje osobní stránky.

A ta podpora cizích klíčů bude taky zajímavá. :) 

To už tam je, protože kvůli tomu jsem to dělal. Ale má to své masařky, viz poslední odstavec tohoto komentáře.

[Mrkva]

Ono hlavne to bez podpory z DB strany nejde. Napr. pri vypadku proudu behem behu skriptu (treba behem commitu vasi "transakce") vam ani to ulozeni na disk nepomuze. Ano, sance ze se neco takoveho stane je mala... Ale je tu. A z mych zkusenosti bych dal jeste jednu radu: bezpecnost je vzdy az na prvnim miste. Takze s timhle:

není pořádná ochrana proti SQL injection (důsledek bodu jedna), asi to nebude tak hrozné (tj. bude to vyžadovat mrknout do kódu před útokem), ale přesto. Nejdříve ale chci dodělat nějaké další featury, tohle už bude jednoduché.

rozhodne nesouhlasim. Nejen, ze je neskutecna otrava to vsechno vyhledavat a doplnovat, ale ono vydat kod a az pak resit bezpecnost neni rozhodne spravny pristup - prave kvuli riziku, ze neco opomenete. Je to jen to co me napadlo pri letmem pohledu do kodu.

[TanisCZ]

Souhlas a pokud se ti to nechtělo dělat, tak si mohl použít už nějaký hotový layer. Třeba takové dibi :o) 

[stativ]

1. Nechci si hrát na něco velkého, samozřejmě že bez popory DB to pořád bude všelijaké řešení. Ovšem pokud chcete, můžete dopsat konektor třeba pro Oracle a pak ta transakčnost bude opravdová. Jako základ můžete vzít mysql-innodb.php, který sice není kompletní a ještě jsem ho ani nezkoušel, ale není tam tolik balastu okolo jako v mysql.php. Můžete si i vygenerovat doxygenem dokumentaci.

2. co se týče SQL statements, tak ty by měly být ošetřené poctivým escapováním a tudíž všechno co je součástí dotazu je escapovaný text v uvozovkách (tudíž místo např SELECT tam bude 'SELECT', což by nemělo dělat nic.). Tudíž žádné strašné hledání. Dále všechny dotazy na databázi mimo administraci jsou v podstatě hardcoded, jediné co se předává jsou identifikátory, které by měly při jakékoli změně na něco jiného než číslo vrátit prázdný výsledek. Ovšem pro jistotu je do budoucna hodlám kontrolovat, jestli je identifikátor číslo, protože věřím, že by se našel nějaký šikula, který by to nějak zvládl oblbnout.

[stativ]

Druha vec se tyka tech "transakci" bez InnoDB. (v tech uvozovkach je to zamerne - nesplnuje to hned dve z charakteristik transakci - zachovani atomicity a konzistence.

Mimochodem, proto tam ty uvozovky mám taky Prostě jako databáze, které transakce nejsou cizí se to chovat nemůže, ale aspoň se to k tomu snaží konvergovat.

[lokki]

Taktiež sa pridávam k tým, čo prajú veľa šťastia ku dotiahnutiu projektu. Na druhej strane sa mi tiež zdá emulácia transakcií zbytočným úsilím (pokiaľ nejde čiste o radosť z programovania). Nebolo by lepšie nechať databázy databázami a nechať každú sa s tým vysporiadať ako sama vie? Pokiaľ viem, na ic.cz je aj postgresql ktorý transakcie podporuje. Na "kritickejšie" nasadenia by sa viac hodil ten.

[stativ]

pokiaľ nejde čiste o radosť z programovania

Jinak bych to nedělal.

Pokiaľ viem, na ic.cz je aj postgresql ktorý transakcie podporuje. Na "kritickejšie" nasadenia by sa viac hodil ten.

Zatím se mi ho nechtělo instalovat, ale možná pro něj v budoucnu udělám backend.

[Luk]

Zatím se mi ho nechtělo instalovat, ale možná pro něj v budoucnu udělám backend.

Pro "základní" věci (bez využívání specifik jednotlivých databází) není v PHP ani potřeba dělat specifické backendy pro různé DBMS. Úplně nejtriviálněji je to řešitelné tak, že se názvy jednotlivých funkcí sestavují v runtime na základě názvu databáze (mysql, pg, ibase apod.), který je někde v konfiguraci, a generického názvu funkce. Je pochopitelně otázka, jakou režii má kód typu:

$fnc = $dbname."_query";
$res = $fnc($sql);

oproti "obvyklému" kódu:

$res = mysql_query($sql);

(kde místo mysql_query samozřejmě může být třeba ibase_query() nebo něco jiného).

[Non_E]

Proč místo toho nepoužít PDO?

[Luk]

Z více důvodů. Zaprvé mnoho hostingů PDO nemá - buď mají PHP bez zakompilovaného PDO a jeho ovladače pro MySQL, anebo mají PHP 5.0, kde PDO nebylo (přidávalo se z PECL). Zadruhé přidává poměrně dost velkou režii.

Když už používat něco jiného, než tu trivialitu kterou jsem uvedl, tak lze použít například dibi. Není to ještě úplně hotové, ale nezávisí na žádné speciální komponentě a vypadá hodně zajímavě.

[Non_E]

Klidně dibi. Určitě bych se ale vyhnul navrhovanému škaredému "variable variable" v db layeru.

[Luk]

škaredému "variable variable"

To jsem ukazoval jen jako to nejjednodušší možné univerzální řešení. Jen pro přesnost: není to "variable variable", nýbrž "variable function". A nejde o nic škaredého - je to velmi silný a užitečný nástroj. Samozřejmě je potřeba s ním pracovat opatrně, vzhledem k potenciální nebezpečnosti.

[stativ]

Teď na to dibi koukám a nevypadá to tak špatně, ale nelíbí se mi moc řešení, kdy musím psát SQL statements přímo do funkce. Já si to radši víc zaobalím, protože SQL nerad píšu (už jenom kvůli přesnému pořadí a dalším kravinám). Akorát se trochu hůř hledají chyby, protože člověk ten dotaz přímo nevidí (pokud neodkomentuje výpisy v příslušném backendu). Na druhou stranu to pak nikomu nebrání použít místo relační databáze třeba haldu souborů.

[Daniel Kvasnička ml.]

Teď na to dibi koukám a nevypadá to tak špatně, ale nelíbí se mi moc řešení, kdy musím psát SQL statements přímo do funkce.

Kdyz uz psat SQL rucne, tak by imho melo byt uplne mimo v nejakem univerzalnim formatu (XML, .ini, .properties ...whatever) a v te aplikace by se na to melo odkazovat pres nejake unikatni ID. SQL dotazy rozesete po kodu je peklo udrzovat.

[Josef Kufner]

Ono bohatě stačí si pro každou věc v DB vyrobit třídu a zapouzdřit SQL do ní. Je to jednoduché nenáročné a lze lehce míchat generované a ručně psané SQL dotazy.

[Daniel Kvasnička ml.]

To jo no, ale pokud nahodou dojde na rewrite a volba padne na jiny jazyk, tak v pripade SQL dotazu ulozenych mimo mate kus prace usetreny...

[Josef Kufner]

Myslím, že tohle není až tak vážný problém

[Daniel Kvasnička ml.]

O PDO se da pozadat a treba ho dodaji... na Klenotu jsem to tak mel.

[stativ]

Já tohle používání proměnných ve jménech identifikátoru nemám moc rád, protože mi to přijde nepřehledné.

Další problém je v tom, že bych ten backend musel stejně udělat, protože spousta těch věcí je DB specific a tudíž na standardní funkce php by se to použít nedalo (možností by bylo použít namespace, ale pak by to nebylo kompatibilní se staršími verzemi php 5.x)

Teď jsem chtěl jako ukázku poslat rozdíl v commitTransaction() v implementaci v mysql-innodb.php a onom „obezličkovitém“ mysql.php. Jaksi jsem ale zjistil, že v mysql-innodb.php jsem ho ještě neimplementoval.

[stativ]

PS.: Mimochodem, já jsem spíš C++ -kař a tudíž dávám přednost použití objektů.

[Luk]

Též jsem zvyklý programovat hlavně objektově (Java a C++), ale v PHP používám objekty poměrně málo. Je to částečně zvyk z dřívějška (verze 4 na tom nebyla s objektovostí příliš dobře), částečně mi to tak nějak vyhovuje (i když jsou situace, kdy objekty používám, protože mi to přijde výhodnější).

[TanisCZ]

Tak se vykašli na tuhle kombinace a udělej to v asp.net a mssql :) 

[Josef Kufner]

Hele, a co se na ty transakce vybodnout úplně a seřadit updaty a selecty tak, aby nebyly transakce potřeba? Občas to nejde, ale většinou jo...

[stativ]

Tak to i bylo původně řešeno (a na rovinu, v kódu je už ze zvyku tak řadím), ale problém byl s cizími klíči. Na to jsem používal mysq_inserted_id() nebo jak se ta fce jmenuje, ale znamenalo to možnost použití jenom na generované identifikátory. Tohle je univerzálnější řešení. A jak už jsem psal, přišlo my to jako zajímavý problém k vyřešení.

Navíc tohle se týká jenom jednoho backendu. Když při instalaci zvolíte connector mysql-innodb.php tak se používá transakčních schopností databáze a žádných obezliček. Pomíjím, že to nejspíš nebude fungovat, protože zatím mám veškeré DB jako MyISAM (ono to na databázi Amaroku docela stačí) takže to nemám otestované. Další problém je, a teď na sebe prásknu něco příšerného, – nikdy jsem přímo nepracoval s transakční databází, všechno mám založeno jen na teoretických znalostech vyčtených z manuálů.