Názory ke článku Metatable – ukládáme a vybíráme data v PHP – Programujte.com

zajimaly by me dve veci :)
1) nejake zmereni vykonu - aspon orientacne. treba 50 zaznamu, kolik mi bude trvat vybrani poloviny
2) proc Mercurial a ne SVN?

Ano... Taky bych se zajímal o výkon. Ale jestli to bude na nějaký slušný úrovni, myslím, že to má docela slušnej potenciál... :smile3:

Reagoval na komentář od uživatele Jan Škrášek :
nejake zmereni vykonu
http://bukaj.netuje.cz/play/metatable-bench/ – benchmark poslední verze z repozitáře; spustí se skriptem run.php. Test na zápis celých čísel je schválně dělán tak, aby šlo o nejhorší možný případ.

proc Mercurial a ne SVN?
Důvod je jednoduchý – líbí se mi víc, mám radši distribuované verzovací systémy.

Pozor, řešení s kopií streamu, tmp souborem a následným rename, není dostatečně atomické a může dojít ke kolizi. Pravděpodobnost se snižuje, ale pořád je dosti vysoká. Řešením je vytvořit vlastní stream wrapper a ten následně zaregistrovat. Pěkná implementace je např. v nette - http://latrine.dgx.cz/atomicke-operace-jeste-jednou
Nápad je to zajímavý a je jasné, že pro menší datové velikosti, může mít využití. Velkou optimalizací by bylo použit nějakou sdílenou paměť jako backend (např. memcache), čímž se už ale ztratí ta nezávislost na extensions. No co, ramdisk se dá použít skoro vždy :-)

Určitě si ale dejte pozor na strukturu projektu, přecejenom třída o 1249 řádcích (aktuální repository i s komentáři) není už úplně ideální. Zrovna to ukládání by se hodilo oddělit do nějakého adaptéru, což by otevřelo dveře implementací s memcache či APC, závislost adaptéru by se pak mohla řešit pomocí interface (zde je pro inspiraci skvělé Zend_Cache).

Táké nevidím moc důvodů, aby výsledná třída byla final, ale to je věcí názoru.

Rozhodně to mé názory neberte nějak špatně, spousta myšlenek se mi libí : )
Zkusím si najít nějaký čas a poslat patch, třeba bude akceptován : )

Btw1: v repository mi chybí unittesty, možná jsem je ale přehlédl.
Btw2: řešení "Náhledu" na zdejším webu je hrozné : ) Málem jsem přišel o celý tento román.

Reagoval na komentář od uživatele LesTR :
Pozor, řešení s kopií streamu, tmp souborem a následným rename, není dostatečně atomické a může dojít ke kolizi.
Atomické to je. Ovšem přivedlo mě to na jiný problém, když metatable čeká na zámek, má otevřenou ještě starou kopii souboru, takže se nedostane k datům, která mohla změnit jiná instance. Nejspíš tím bylo myšleno toto.

Potíž je v tom, že tohle ani Nette\SafeStream nevyřeší, protože je potřeba, aby všechno mezi otevřením tabulky (metatable::open()) a zavřením ($metatable->close()) bylo atomické, tudíž nelze jakkoli měnit obsah samotného souboru s tabulkou (na který mám zámek) a všechno musí probíhat právě nad dočasně vytvořenou kopií. Která je nakonec přejmenována (což je atomické).

Východiskem, které mě napadlo, je kontrolovat při konečném získání zámku při otevírání inode, jestli se shoduje s inodem, na který odkazuje název souboru s tabulkou, a zámek uvolňovat až po úspěšném přejmenování. Jak už to tak bývá, i tohle má své proti – nejsem si jistý, jak to bude s Windows (myslím, že to tam takhle nepůjde). Nevím, jestli zavrhnout Windows ve prospěch bezchybnatého řešení.

Velkou optimalizací by bylo použit nějakou sdílenou paměť jako backend (např. memcache)
Cachování je možné přidělat jako nadstavbu. Už takhle metatable řeší dost věcí naráz, což se mně samotnému nelíbí. Docela to souvisí s tím následujícím…

Zrovna to ukládání by se hodilo oddělit do nějakého adaptéru, což by otevřelo dveře implementací s memcache či APC
Popřemýšlím o tom, nezní to vůbec špatně. Ale zase se mi z toho nechce dělat nějaké obludné monstrum.

Táké nevidím moc důvodů, aby výsledná třída byla final, ale to je věcí názoru.
Nevidím důvod, aby někdo z metatable dědil, a ani není záhodno, aby se tak dělo. Jsem zastáncem co nejplošší hierarchie tříd. Pokud se někomu něco v kódu nelíbí, nechť ho upraví (a pošle patch; pokud se mi zalíbí, bude začleněn :-)). Pokud by bylo potřeba vytvořit nějakou to cachovací vrstvu, viděl bych to na interface – metatableable (lepší název vítán).

hlásí mi to chybu na 1077 řádku: Fatal error: Call to undefined function sys_get_temp_dir()

jelikož se v tomto kodu ještě uplně neorientuji chtěl bych se zeptat co tato chyba znamená

Reagoval na komentář od uživatele 3366 :
Fatal error: Call to undefined function sys_get_temp_dir()
sys_get_temp_dir() vrací cestu k adresáři na ukládání dočasných souborů (na Unixech např. typicky /tmp, u Windows myslím C:\Temp). sys_get_temp_dir() je dostupný až od PHP 5.2.1, takže to bude nejspíše verzí PHP. Jelikož je tu verze 5.2.1 od 8. února 2007, označuji tento bug jako WONTFIX. Východiskem je aktualizovat PHP.

Nenechala by se funkce sys_get_temp_dir() nahradit, tak aby METATABLE byla spustitelná na PHP 5.2.0

Reagoval na komentář od uživatele Jakub Kulhan :
bohuzel na debianech je 5.2.0 standard... odriznout kvuli tomu tolik uzivatelu....

Reagoval na komentář od uživatele Jan Škrášek :
Nemyslim upravit tuto verzi teda ano, ale publikovat to jako Metatable for PHP 5.2.0 nebo tak něco. Já vím je to práce navíc, ale tím by se spíš rozšířily řady spokojených uživatelů určitě bych mezi nimi byl i já ... Předem díky

Reagoval na komentář od uživatele 3366 :
Nahrazovat se nebude... Tak si ji vytvoříme, když ji PHP < 5.2.1 nemá :-) Inspiroval jsem se komentáři na php.net a pokud fce sys_get_temp_dir() neexistuje, tak si ji to vytvoří.

Zdrojový kód buď v Mercurial repozitáři na Google code[1], nebo ještě taky v Gitím repozitáři na github.com[2]. Pokud se nechce používat Hg, či Git, tak pro archiv s kódy je na githubu tlačítko download.

[1] http://code.google.com/p/metatable/source/checkout
[2] http://github.com/jakubkulhan/metatable/tree/experimental

Jsem amater a toto vubec nevim:D a nevygooglil jsem, jak pracuje v php

Reagoval na komentář od uživatele H4UnT3R :
Data zabírají paměť (operační, diskovou…) a garbage collection je proces, který se stará o uvolňování paměti (a vůbec zdrojů) dat, které už nejsou potřeba. Doporučuji přečíst seriál o garbage collection tady na programujte[1].

metatable pracuje tak, že všechny řetězce jsou ukládány na zvláštní místo v souboru (do jednoho ze souborových rámců /en frame/; něco o formátu je na stránkách na GitHubu[2]). metatable využívá kopírovací garbage collector (viz odkazovaný seriál) – tzn. že všechny řetězce, které jsou referencovány z rámce dat, jsou zkopírovány na nové místo a odkazy na řetězce jsou změněny.

[1] http://programujte.com/?akce=clanek&cl=2008060900-jemny-uvod-do-garbage-collection
[2] http://jakubkulhan.github.com/metatable/format.html