abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 0
včera 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
včera 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
včera 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
včera 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 2
včera 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
13.12. 11:00 | Zajímavý software
Na Good Old Games je v rámci aktuálních zimních slev zdarma k dispozici remasterovaná verze klasické point&click adventury Grim Fandango, a to bez DRM a pro mainstreamové OS včetně GNU/Linuxu. Akce trvá do 14. prosince, 15:00 SEČ.
Fluttershy, yay! | Komentářů: 6
13.12. 07:22 | Pozvánky

Konference InstallFest 2018 proběhne o víkendu 3. a 4. března 2018 v Praze na Karlově náměstí 13. Spuštěno bylo CFP. Přihlásit přednášku nebo workshop lze do 18. ledna 2018.

Ladislav Hagara | Komentářů: 0
12.12. 20:22 | Nová verze

Před měsícem byla vydána Fedora 27 ve dvou edicích: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server byl "vzhledem k náročnosti přechodu na modularitu" vydán pouze v betaverzi. Finální verze byla naplánována na leden 2018. Plán byl zrušen. Fedora 27 Server byl vydán již dnes. Jedná se ale o "klasický" server. Modularita se odkládá.

Ladislav Hagara | Komentářů: 6
12.12. 10:22 | Zajímavý článek

Lukáš Růžička v článku Kuchařka naší Růži aneb vaříme rychlou polévku z Beameru na MojeFedora.cz ukazuje "jak si rychle vytvořit prezentaci v LaTeXu, aniž bychom se přitom pouštěli do jeho bezedných hlubin".

Ladislav Hagara | Komentářů: 13
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 987 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Lehký úvod do CouchDB – 1 (základní API)

    27. 1. 2010 | Ladislav Thon | Programování | 9390×

    V posledních letech získává na oblibě zejména mezi webovými programátory jistý druh nerelačních databází, které můžeme souhrnně označit jako bezschémové. V tomto trojdílném seriálu si představíme jednu z nich, která se těší poměrně velké popularitě, totiž CouchDB. V prvním díle si na příkladech popíšeme prakticky celé základní API.

    Obsah

    Půjdeme na to čistě prakticky, teorii si můžeme nechat na později. CouchDB je dnes ve verzi 0.10.1, kterou najdete kupříkladu v Debianu unstable. V testingu je 0.10.0, což nám postačí, takže např. aptitude install couchdb a s chutí do toho; uživatelé jiných distribucí si snad poradí sami, případně se obrátí na wiki. Lehký přehled o vnitřnostech získáte třeba v technical overview – pro nás to teď nebude nutné, ale zájemcům vřele doporučuji. CouchDB se mimochodem používá například jako lokální úložiště dat pro Ubuntu One (viz též desktopcouch), což znamená, že vydáním Ubuntu 9.10 se zvýšil podíl instalací Erlangu na osobních počítačích minimálně o stovky procent :-)

    Úplné základy čili CRUD (Create, Read, Update, Delete)

    link

    CouchDB má jediné API: JSON přenášený přes HTTP. Skutečně, je to tak, můžete si pohrát třeba z příkazové řádky a HTTP klienta najdete snad pro jakýkoliv programovací jazyk. Server poslouchá na portu 5984, takže pro seznámení:

    $ curl -X GET http://localhost:5984/
    {"couchdb":"Welcome","version":"0.10.1"}
    $ curl -X GET http://localhost:5984/_all_dbs
    []

    Aha, ještě žádnou databázi nemáme vytvořenou! To snadno napravíme. API je RESTové, vytvořit novou kolekci objektů znamená volat PUT. A když jsme v tom, smazání je pochopitelně DELETE.

    $ curl -X PUT http://localhost:5984/pokus
    {"ok":true}
    $ curl -X GET http://localhost:5984/_all_dbs
    ["pokus"]
    $ curl -X DELETE http://localhost:5984/pokus
    {"ok":true}
    $ curl -X GET http://localhost:5984/_all_dbs
    []

    Poznatek: „systémové“ identifikátory začínají podtržítkem.

    Na ten DELETE na chvilku zapomeňme, řekněme, že tedy máme databázi pokus. Jen tak na hraní. Mějme dokument… nějaký pěkný, třeba tenhle:

    {"type": "book", "author": "Dan Simmons", "name": "Drood"}

    Co s ním?

    $ curl -X POST -d '{"type": "book", "author": "Dan Simmons", "name": "Drood"}' http://localhost:5984/pokus
    {"ok":true,"id":"317d691f7c21937824bf9b55e1994486","rev":"1-4ffc368db414b81bf524c6d4c421b93f"}

    POST volaný na kolekci znamená vytvořit v ní nový objekt a automaticky mu přiřadit ID. Což se také stalo:

    $ curl -X GET http://localhost:5984/pokus/317d691f7c21937824bf9b55e1994486
    {"_id":"317d691f7c21937824bf9b55e1994486","_rev":"1-4ffc368db414b81bf524c6d4c421b93f",
      "type":"book","author":"Dan Simmons","name":"Drood"}

    (Pro snazší čtení odřádkovávám a odsazuji dvěma mezerami.)

    Now come on, it can't be that simple, can it? Poznatek: CouchDB patří mezi dokumentové databáze, kterým není nutné předem říkat, jaká bude struktura ukládaných dat. Datové schéma je čistě věcí aplikace.

    Řekněme, že bychom chtěli ukládat i žánrové zařazení. Nebo spíš žánrová zařazení, těch může být vždycky víc. Aktualizace existujícího objektu je PUT:

    $ curl -X PUT -d '{"_id":"317d691f7c21937824bf9b55e1994486","_rev":"1-4ffc368db414b81bf524c6d4c421b93f",
      "type":"book","author":"Dan Simmons","name":"Drood", "genres": ["fantasy", "thriller", "detektivka"]}'
      http://localhost:5984/pokus/317d691f7c21937824bf9b55e1994486
    {"ok":true,"id":"317d691f7c21937824bf9b55e1994486","rev":"2-fa897debf5c1a63193f121798e85b6e3"}

    Nešálí vás zrak, jako jednu z položek jsem opravdu uložil seznam. Když se mi zlíbí, do toho seznamu si můžu klidně uložit třeba další dokumenty (mapy, hashe), není v tom problém. A pokud nevadí tohle – neměly by ty žánry být někde v číselníku a u knihy jenom odkazy do něj? Hm, člověk nikdy neví, tak prozatím řekněme, že žánry jsou pro nás něco jako tagy na webu a uvidíme, co s nimi dál.

    Ostatně, když jsme u toho, co ten autor? Ten by přece určitě měl být uložený samostatně a u knihy by na něj měl být jen odkaz, ne? Přijde na to – v jednom mém oblíbeném webovém knihkupectví například vůbec nemají stránky autorů a umí podle jejich jmen jen vyhledávat.

    Revize dokumentu čili současný přístup více uživatelů

    link

    A protože v tuhle chvíli z otázek až oči přecházejí, na chvilku zpomalíme a podíváme se na záhadné položky _id_rev. _id je, inu, ID, jednoznačný klíč, podle kterého lze dokument najít. ID si můžu nechat generovat od CouchDB při vytváření nových dokumentů, jako tomu bylo výše (v takovém případě se vyrobí nové UUID), nebo si ho zadat sám:

    $ curl -X PUT -d '{"type": "book", "author": "Orson Scott Card", "name": "Enderova hra",
      "genres": ["sci-fi", "humanismus"]}' http://localhost:5984/pokus/enderova-hra
    {"ok":true,"id":"enderova-hra","rev":"1-0b1b7e88639474892f4eb950bf139e27"}
    $ curl -X GET http://localhost:5984/pokus/enderova-hra
    {"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27","type":"book",
      "author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"]}

    Automatické generování UUIDů je víc než vhodné minimálně v případě, kdy je databáze „distribuovaná“ (CouchDB disponuje hezkou funkcí replikace s řešením konfliktů, ale tím se teď zabývat nebudeme). Naopak číselná ID v rostoucí posloupnosti mohou být pro databázi příjemnější kvůli způsobu, jakým jsou ukládána a vyhledávána data (už jsem říkal, že základní a vlastně jedinou diskovou strukturou CouchDB je B-strom?).

    A co to _rev? Jistě, je to od slova revision, což ovšem neznamená, že by se CouchDB dala použít jako verzovací systém. Číslo revize slouží k řešení současného přístupu k datům: Už výše jsme viděli, že když chci dokument změnit, musím ho poslat včetně položky _rev. CouchDB povolí zápis jen tehdy, pokud se číslo revize v ukládaném dokumentu shoduje s aktuálně platným číslem revize v databázi.

    $ curl -X PUT -d '{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27",
      "type":"book","author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
      "stars": "5/5"}' http://localhost:5984/pokus/enderova-hra
    {"ok":true,"id":"enderova-hra","rev":"2-823eb2f692da425220f17b96b231082b"}
    $ curl -X PUT -d '{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27",
      "type":"book","author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
      "stars": "6/5"}' http://localhost:5984/pokus/enderova-hra
    {"error":"conflict","reason":"Document update conflict."}
    $ curl -X PUT -d '{"_id":"enderova-hra","_rev":"2-823eb2f692da425220f17b96b231082b",
      "type":"book","author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
      "stars": "6/5"}' http://localhost:5984/pokus/enderova-hra
    {"ok":true,"id":"enderova-hra","rev":"3-1be8a2371b004f49b284061433ba9b48"}

    Staré revize je stále možné získat, ovšem pouze tehdy, pokud jsou v databázi ještě dostupné.

    $ curl -X GET http://localhost:5984/pokus/enderova-hra?rev=1-0b1b7e88639474892f4eb950bf139e27
    {"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27","type":"book",
      "author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"]}
    $ curl -X POST http://localhost:5984/pokus/_compact
    {"ok":true}
    $ curl -X GET http://localhost:5984/pokus/enderova-hra?rev=1-0b1b7e88639474892f4eb950bf139e27
    {"error":"not_found","reason":"missing"}

    Poznatek: CouchDB používá multigenerační architekturu a řešení souběžných přístupů je tedy optimistické. Garbage collector (compact) je, pokud vím, nutné volat ručně (viz též wiki) a po dobu jeho běhu lze databázi normálně používat.

    Bližší informace o revizích dokumentu získáte použitím parametrů revs=true nebo revs_info=true:

    $ curl -X GET http://localhost:5984/pokus/enderova-hra?revs_info=true
    {"_id":"enderova-hra","_rev":"3-1be8a2371b004f49b284061433ba9b48","type":"book",
      "author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
      "stars":"6/5","_revs_info":[
        {"rev":"3-1be8a2371b004f49b284061433ba9b48","status":"available"},
        {"rev":"2-823eb2f692da425220f17b96b231082b","status":"missing"},
        {"rev":"1-0b1b7e88639474892f4eb950bf139e27","status":"missing"}
      ]}

    Obdobně funguje mazání: Je to vlastně vytvoření nové revize.

    $ curl -X DELETE http://localhost:5984/pokus/enderova-hra
    {"error":"conflict","reason":"Document update conflict."}
    $ curl -X DELETE http://localhost:5984/pokus/enderova-hra?rev=3-1be8a2371b004f49b284061433ba9b48
    {"ok":true,"id":"enderova-hra","rev":"4-d71e7ad84ec3801b0504b739e925e8b7"}
    $ curl -X GET http://localhost:5984/pokus/enderova-hra
    {"error":"not_found","reason":"deleted"}

    Dotazy čili pohledy čili indexy

    link

    Nu, takže základní operace s dokumenty máme za sebou, co dál? Ovšem, dotazy. SQL? Ale kdeže, JavaScript! JavaScript a MapReduce. Přidejme si nejdřív pár dalších knih, ať je to zajímavější:

    $ curl -X POST -d '{"type": "book", "author": "Dan Simmons", "name": "Ílion",
      "genres": ["sci-fi"]}' http://localhost:5984/pokus
    {"ok":true,"id":"4ac9d40eff110178bfbb73d0e2c808bc","rev":"1-987ed35e7539446335290fb6ef1ed909"}
    $ curl -X POST -d '{"type": "book", "author": "Dan Simmons", "name": "Olymp",
      "genres": ["sci-fi"]}' http://localhost:5984/pokus
    {"ok":true,"id":"0ddd69f92f541e27b554f3ebed1d87a3","rev":"1-b4e1ebabd59a3bb677f1d00cb3a2c935"}
    $ curl -X POST -d '{"type": "book", "author": "Orson Scott Card", "name": "Enderova hra",
      "genres": ["sci-fi", "humanismus"]}' http://localhost:5984/pokus
    {"ok":true,"id":"59403880473a6bda402a21d64ad8c4cf","rev":"1-0b1b7e88639474892f4eb950bf139e27"}
    $ curl -X POST -d '{"type": "book", "author": "Orson Scott Card", "name": "Sedmý syn",
      "genres": ["fantasy"]}' http://localhost:5984/pokus
    {"ok":true,"id":"7e3891e4e1b5cf147137a0b0d609420e","rev":"1-ce3f425332eff2edd000b059a1aee8b9"}
    $ curl -X POST -d '{"type": "book", "author": "Orson Scott Card", "name": "Rudý prorok",
      "genres": ["fantasy"]}' http://localhost:5984/pokus
    {"ok":true,"id":"309a09f8ea790c232472cb66049fa2dd","rev":"1-9a1af3cbc31c3b1a3dc5dacc131a9003"}
    $ curl -X POST -d '{"type": "book", "author": "Orson Scott Card", "name": "Učedník Alvin",
      "genres": ["fantasy"]}' http://localhost:5984/pokus
    {"ok":true,"id":"82df2dd330d5c426d7509789fdda9bb8","rev":"1-42c1f75fc1046ed1c458b0b670bb61ef"}

    Pozn.: Kódování znaků musí být utf-8, případně lze používat klasické unicode escape sekvence \uNNNN.

    A co dál? Třeba jména knih podle žánrů:

    // map
    function(doc) {
      if (doc.type == "book" && doc.genres) {
        for (var genre in doc.genres) {
          emit(doc.genres[genre], doc.name);
        }
      }
    }

    Hodně… neobvyklé, to přinejmenším. Pojďme se na to podívat podrobněji: CouchDB má pohledy. Ty pohledy jsou definovány jednou nebo dvěma funkcemi v programovacím jazyce (konkrétně v JavaScriptu, ale rozhraní je obecné a existuje podpora pro další jazyky, viz wiki). Názvy těch funkcí pocházejí z funkcionálního světa: mapreduce, a nesou si z něj ještě jednu vlastnost: Musí být idempotentní. To zjednodušeně znamená, že nesmí nic změnit (pro jeden dokument musí za každých okolností vrátit tu samou hodnotu, nepřichází v úvahu ani žádné globální proměnné), a to zase zjednodušeně vede ke krásným důsledkům: Pohledy lze počítat inkrementálně a paralelně. Funkce map je povinná a slouží k filtrování a transformování. Je zavolána pro každý dokument v databázi a sama každým voláním emit generuje jednu položku pohledu: Dvojici <klíč; hodnota> (v příkladu výše <žánr; název knihy>). Funkce reduce je nepovinná, takže ji na chviličku vynecháme. Výsledky se ukládají na disk (takže ten pohled je vlastně materializovaný), a to vždy seřazené podle klíče (takže je to vlastně i index).

    Teď jak tedy tu funkci do databáze dostat. Z řádky už mě to nebaví, takže si v prohlížeči otevřu http://localhost:5984/_utils, kde se nachází Futon, webové GUI ke CouchDB. Futon je z velké části javascriptová aplikace, s CouchDB komunikuje AJAXem stejným způsobem, jako jsme si to předvedli výše. Vlezu do databáze pokus a vpravo nahoře zvolím View: Temporary view… Do pole Map Function vložím kód uvedený výše a tlačítkem Run si můžu hned zobrazit výsledky:

    couchdb1 pohled

    To je dočasný pohled, ten ještě není uložený na disku a pokaždé se počítá znovu. Tak tedy Save As…, Design Document: _design/books, View Name: by_genreSave. Když pak opět vpravo nahoře zvolím View: All documents, vidím, že v databázi vznikl nový dokument s ID _design/books. Zkuste se podívat na jeho obsah, případně pod záložkou Source se skrývá čistý JSON.

    $ curl -X GET http://localhost:5984/pokus/_design/books/_view/by_genre
    {"total_rows":10,"offset":0,"rows":[
    {"id":"317d691f7c21937824bf9b55e1994486","key":"detektivka","value":"Drood"},
    {"id":"309a09f8ea790c232472cb66049fa2dd","key":"fantasy","value":"Rud\u00fd prorok"},
    {"id":"317d691f7c21937824bf9b55e1994486","key":"fantasy","value":"Drood"},
    {"id":"7e3891e4e1b5cf147137a0b0d609420e","key":"fantasy","value":"Sedm\u00fd syn"},
    {"id":"82df2dd330d5c426d7509789fdda9bb8","key":"fantasy","value":"U\u010dedn\u00edk Alvin"},
    {"id":"59403880473a6bda402a21d64ad8c4cf","key":"humanismus","value":"Enderova hra"},
    {"id":"0ddd69f92f541e27b554f3ebed1d87a3","key":"sci-fi","value":"Olymp"},
    {"id":"4ac9d40eff110178bfbb73d0e2c808bc","key":"sci-fi","value":"\u00cdlion"},
    {"id":"59403880473a6bda402a21d64ad8c4cf","key":"sci-fi","value":"Enderova hra"},
    {"id":"317d691f7c21937824bf9b55e1994486","key":"thriller","value":"Drood"}
    ]}
    $ curl -X GET 'http://localhost:5984/pokus/_design/books/_view/by_genre?key="sci-fi"'
    {"total_rows":10,"offset":6,"rows":[
    {"id":"0ddd69f92f541e27b554f3ebed1d87a3","key":"sci-fi","value":"Olymp"},
    {"id":"4ac9d40eff110178bfbb73d0e2c808bc","key":"sci-fi","value":"\u00cdlion"},
    {"id":"59403880473a6bda402a21d64ad8c4cf","key":"sci-fi","value":"Enderova hra"}
    ]}
    $ curl -X GET 'http://localhost:5984/pokus/_design/books/_view/by_genre?startkey="a"&endkey="n"'
    {"total_rows":10,"offset":0,"rows":[
    {"id":"317d691f7c21937824bf9b55e1994486","key":"detektivka","value":"Drood"},
    {"id":"309a09f8ea790c232472cb66049fa2dd","key":"fantasy","value":"Rud\u00fd prorok"},
    {"id":"317d691f7c21937824bf9b55e1994486","key":"fantasy","value":"Drood"},
    {"id":"7e3891e4e1b5cf147137a0b0d609420e","key":"fantasy","value":"Sedm\u00fd syn"},
    {"id":"82df2dd330d5c426d7509789fdda9bb8","key":"fantasy","value":"U\u010dedn\u00edk Alvin"},
    {"id":"59403880473a6bda402a21d64ad8c4cf","key":"humanismus","value":"Enderova hra"}
    ]}

    Vidíme, že výsledky pohledu jsou skutečně řazené podle klíče (key) a nádavkem pro každou položku obsahují ID dokumentu. Parametry key, startkeyendkey musí být platný JSON, proto ty uvozovky. Takže umíme hledat podle hodnoty i podle rozsahu; o dalších možnostech si můžete přečíst na wiki. Podobně jako materializované pohledy v relačních databázích mají pohledy v CouchDB výhodu výborného výkonu: Není potřeba nic počítat, stačí jen číst.

    Dál: Co si trochu zaredukovat? Nepovinná funkce reduce slouží k agregování. Řekněme, že chceme pro každý žánr vědět, kolik knih do něj patří. Zkusíme si takový lehký myšlenkový veletoč:

    // map
    function(doc) {
      if (doc.type == "book" && doc.genres) {
        for (var genre in doc.genres) {
          emit(doc.genres[genre], 1);
        }
      }
    }
    
    // reduce
    function(keys, values, rereduce) {
      // log({"keys": keys, "values": values, "rereduce": rereduce});
      return sum(values);
    }

    Tak tohle už začíná být víc než zvláštní – kdo nikdy neslyšel o MapReduce, bude asi pořádně zmatený. Zkusme trochu osvětlit princip: Pro každý dokument systém zavolá mapovací funkci, která může emitovat libovolně mnoho dvojic <klíč; hodnota>, to už jsme viděli. Všechny takto vyrobené dvojice se vezmou, vyrobí se z nich množina dvojic <klíč; seznam všech hodnot emitovaných pro tento klíč> a pro každou z těchto dvojic se následně zavolá redukční funkce. Ta musí být komutativní a asociativní a musí vždy vrátit právě jednu hodnotu (v našem případě je to číslo, ale může to být klidně i seznam apod.), proto se jí říká redukční.

    V našem případě funkce map vygeneruje pro každou knihu v každém žánru jednu jedničku a funkce reduce ty jedničky po jednotlivých žánrech sčítá.

    $ curl -X GET http://localhost:5984/pokus/_design/books/_view/genres_count?group=true
    {"rows":[
    {"key":"detektivka","value":1},
    {"key":"fantasy","value":4},
    {"key":"humanismus","value":1},
    {"key":"sci-fi","value":3},
    {"key":"thriller","value":1}
    ]}

    S trochou snahy se tenhle princip dá pochopit, je tu ale jeden problém: Výklad výše je ve skutečnosti lež. Redukce v CouchDB neprochází prostřední fází (seskupování hodnot podle klíče). Parametr keys obsahuje pole různých emitovaných klíčů (a také ID dokumentů, ze kterých byly klíče emitovány), parametr values pole odpovídajících emitovaných hodnot. K tomu se ještě přidává skutečnost, že pohledy se v CouchDB vyhodnocují inkrementálně. Kvůli tomu přibývá ještě parametr rereduce: Je-li jeho hodnota true, znamená to, že redukční funkce nedostane na vstup hodnoty z mapovací funkce, ale musí zkombinovat svoje vlastní předchozí výstupy. Ty jsou v parametru values, v parametru keys je v takovém případě null.

    Protože tohle už je poměrně vysoká magie a detailní vysvětlení předchozího odstavce by zabralo celý další článek, odkazuji na wiki a přidávám jeden užitečný tip: Jak vidno na zakomentovaném řádku v kódu výše, při vyhodnocování javascriptových funkcí v CouchDB lze logovat. (Zkuste si to, log je ve /var/log/couchdb/couch.log). Každopádně když nic jiného, můžete těchto pár odstavců brát jako ukázku způsobu, kterým se dneska hromadně zpracovávají obrovské objemy dat – na ad hoc dotazování to ovšem stojí za starou belu. Pro tyto účely je asi nejlepší použít couchdb-lucene (i když například vývojáři Mozilla Raindropu používají techniku zvanou Megaview).

    Poznatek: Indexované MapReduce pohledy jsou silná zbraň, ale v ad hoc dotazování je CouchDB slabý.

    Příště

    link

    A to by bylo dneska všechno. Příště se podíváme, jak tedy uložit toho autora, jak k dokumentu přidat přílohu, jak validovat ukládaná data nebo přímo z databáze servírovat HTML.

           

    Hodnocení: 94 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    27.1.2010 08:52 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Ten reduce-process se pak provádí v JavaScriptu? Když pominu možnost paralelizace, není to přesto pomalé? Nebo se to překlopí do něčeho jiného?
    27.1.2010 09:15 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Generování obřích pohledů trvá opravdu dlouho, ale pro spoustu účelů je to rychlé až až. Nejsem si jistý, jestli myslíš rychlost javascriptu (používá se mozillí implementace, ale teď nevím, jestli už TraceMonkey), nebo rychlost komunikace [erlangový proces CouchDB] <-> [proces view serveru, tedy obvykle céčkové couchjs], každopádně view server lze mít v jakémkoli jazyce a pro opravdu náročné je možné psát pohledy přímo v Erlangu :-)
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    okbob avatar 27.1.2010 10:02 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Jádro pudla je v >>inkrementální<< aktualizaci. Zátěž se rozloží v čase.
    27.1.2010 10:56 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Ano. Ale když pohled nějakou dobu nepoužíváš a pak ho najednou potřebuješ, tak stejně čekáš hodinu.
    okbob avatar 27.1.2010 11:24 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Nejsem si jistý, ale myslím si, že není důvod proč by se tak mělo chovat - je to určitá analogie materializovaných pohledů - maximálně může zdržovat než se agregované hodnoty načtou z disku - ale jedná se už o agregované hodnoty - tj funkce map a reduce se při zobrazení neprovádějí.
    27.1.2010 11:51 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Pokud jsem od posledního přístupu k pohledu změnil/přidal gigabajty dat, tak se ty gigabajty dat budou muset někdy naindexovat. A protože se indexy (pohledy) neaktualizují průběžně, ale až při přístupu na ně, tak si pak také počkám...
    okbob avatar 27.1.2010 12:59 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    To právě že ne. Proč si myslíte, že se indexy aktualizují až při přístupu?
    27.1.2010 13:20 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Proč si myslím, že se aktualizují až při přístupu? Protože na jejich aktualizaci čekám, když na ně přistoupím. I ve Statusu (ve Futonu) je vidět, jak se aktualizují. (Verze 0.10.1, bez zásadních změn nastavení.)
    okbob avatar 27.1.2010 13:44 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    tak to pak mají blbě - to by bylo pro provoz nepoužitelný - tipoval bych si, že v tom bude nějaký háček.
    27.1.2010 13:54 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    27.1.2010 15:31 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Pohledy se skutečně aktualizují až při přístupu na ně. Kontrolu aktuálnosti ale můžete přeskočit (stale=ok) a aktualizovat na pozadí. Viz též http://wiki.apache.org/couchdb/Regenerating_views_on_update.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    27.1.2010 11:07
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Lze psat ty view i v Erlangu, coz odpadne vas problem. Lze pouzit i jine jazyky. Napriklad Ruby...

    http://github.com/candlerb/couchdb_ruby_view
    Amarok avatar 27.1.2010 09:26 Amarok | skóre: 33 | blog: blogoblog
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Pozitivne hodnotim mnozstvi prikladu. Nicmene smysl clanku je navnadit na tento typ databazi, coz u me nefungovalo, jeste vic me to odradilo :-/ To se musi pouzivat ten curl, nebo existuje aspon i nejaky interaktivni klient?
    GNUniverse - May the source be with you...
    alblaho avatar 27.1.2010 10:13 alblaho | skóre: 17 | blog: alblog
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Má to i nějaké nějaké hezčí rozhraní přímo v prohlížeči. Říkají tomu Futon.

    http://couchdb.apache.org/screenshots.html

    Pokud vím, tak existují různé javascriptové udělátka, které umožní jakýsi "vývoj" "aplikaci" i přímo v prohlížeči. Víc ví Ládíček :-)

    Mně se ty curl examply právě líbí, ukazuje to pravou podstatu technologie.
    27.1.2010 15:34 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Proč jenom curl? Je to úplně normální HTTP, můžete použít cokoliv, co se umí tvářit jako HTTP klient. Pro spoustu jazyků jsou dostupné přímo knihovny zaměřené na CouchDB, ale těmi jsem článek nechtěl zatěžovat. Pár odkazů bude v posledním díle, ale Google rád poradí :-)
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    27.1.2010 11:08 kkaarreell | skóre: 6 | blog: perkele
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    No jeje, takova mila vzpominka na temer zapomenuty flame. :-D No uvidime...
    Přemek Vyhnal avatar 27.1.2010 15:26 Přemek Vyhnal | skóre: 24 | blog: Toto není blog! | Dobřichovice
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Super! Vypada to fakt pekne ;)
    NO RAPTORS!
    28.1.2010 03:25 balki
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Trosku mi chyba teoria okolo toho, v com spociva nerelacnost, bezschemovost, kedy je vhodnejsie pouzit takuto datbazu atd ...

    Inac pekny clanok, len ked sa hovori o couchDB, mi vzdy unika preco, naco, zaco ....
    28.1.2010 09:18 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Já nejsem žádný velký databázový teoretik, takže ve třetím dílu jsem to shrnul asi takhle: vysoce strukturovaná data, jejichž forma se moc nemění => relační databáze, data v podobě dokumentů nebo objektů, časté změny struktury => dokumentová databáze. To je samozřejmě velké zjednodušení a do hry vstupuje řada dalších faktorů (jsou i další druhy databází a další případy použití, všichni znají SQL, …), takže jsem se snažil napsat seriál tak, aby čtenář získal dost informací na to, aby se rozhodl sám :-)
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    28.1.2010 23:59 balki
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Aha, chapem, takze

    Relacne databazy - tabulky su tvorene n-ticami o pevnej sirke. Naviac v kazdej n-tici je pritomny kluc, ktory jednoznacne identifikuje n-ticu. Vyhoda: je garantovane, ze iste operacie na tejto tabulke pojdu spravit Nevyhoda: siroke tabulky, respektive potreba ich normalizacie ako vysledok je potom kopec poloprazdnych tabuliek. Vyhoda: je garantovane, ze iste operacie pojdu spravit.

    Nerelacne - Stlpce nemaju pevnu sirku, ani tie kluce tam nemusia byt. Vyhoda - volnym okom lepsie citatelne data Nevyhoda - clovek nevie vobec, aky bude vysledok po nejakom query. :)

    To je moj zjednoduseny pohlad :)
    29.1.2010 00:47 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Jak jsi zmínil normalizaci, vzpomněl jsem si na další argument. Normalizovaná SQL databáze (resp. schéma databáze) vypadá pěkně a ve škole se to tak učí dělat, a funguje to pěkně, dokud se všechno nějakým způsobem vejde do diskové cache. Až vám kvůli znormalizovaným datům rozlezlým do sta míst v různých tabulkách (tj. sto různých míst na disku) začne hodně seekovat disk, začnete denormalizovat a nakonec se dostanete k něčemu, co bude dokumentovou databázi docela dost připomínat :)
    29.1.2010 02:03 balki
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Uz to je offtopic: Ale normalne sa to ma robit pri navrhu takto: chaos -> normalizacia -> denormalizacia.

    Pricom vysledne entity maju ovela lepsiu strukturu ako povodny chaos, ale su menej vypoctovo narocne ako normalizovana forma.

    To len tak :)
    28.1.2010 12:45 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Vzhledem k jednoduchosti (je to v podstatě key-value databáze) by tyto "NoSQL" databáze měly být rychlejší než tradiční SQL databáze a mít lepší možnosti škálování (a to někde úplně jinde, než nějaké master-slave u MySQL); proto by měly být vhodnější i pro velké objemy dat. Jak moc to splňuje zrovna CouchDB ponechám na vašem úsudku :)
    28.1.2010 13:02 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    NoSQL databáze se obvykle rozlišují na key-value úložiště, sloupcové databáze, dokumentové databáze a grafové databáze. Samozřejmě nerelačních databází je ještě víc druhů, ale jak říkám, tohle je v hnutí NoSQL takové obvyklé rozdělení. CouchDB je dokumentová databáze, nikoliv key-value store, i když je dost jednoduchá. Třeba takové MongoDB je mnohem složitější (přejímá některé vysokoúrovňové principy z relačních databází, třeba explicitní rozdělení databáze na jednotlivé kolekce nebo "normální" indexování a dotazování).
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    28.1.2010 13:51 osvc01
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    kdyz uz se tu nekdo ptal na to, k cemu to je, tak bych rad prednesl aktualni problem:

    prave se potykam s nabidkou udelat webovou prezentaci, ktera je vlastne jednoducha co se graficke upravy tyce. Data, ktera se maji zobrazovat jsou v desetitisici word-dokumnetech. Kazdy takovy word dokument je castecne strukturovany - neco jako manualove stranky v unixu -> tedy odstavce textu maji nadpisy (nemoc, diagnoza, komplikace ... ano je to z oblasti lekarstvi a tito lide maji skutecne tezkosti neco strukturovat - vymlatit z nich, co vlastne chteji bude asi ten nejvetsi problem).

    Samozrejme, ze ty word dokumenty obsahuji obrazky a take tabulky, seznamy apod. Nyni stojime pred rozhodnutim, co na to vzit. Urcite by bylo mozne rozsekat ty word dokumenty na casti, ktere by pak byly takrikajic ulozeny pod odpovidajicim sloupeckem v rel. databazi. Datovy typ takoveho sloupce je pak nejaky velky text. Uz z toho je videt, jak krkolomne by to v rel databazi bylo a jak se na to nehodi = ta rel. databaze vubec nic neprinese. Myslim si, ze to je presne pripad, kdy vyuzit NoSQL db.

    Myslim, ze takovych pripadu bude pribyvat. Ve firmach je mnozstvi dokumentu, ktere se valeji po ruznych pocitacich vsecch spolupracovniku, pozoruji snahu ve firmach dostat do toho nejaky poradek.
    Heron avatar 28.1.2010 15:19 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Upřímně řečeno ani v tomhle příkladě nevidím výhody NoSQL nad SQL. Tak jako tak ty word dokumenty musíte nějakým způsobem zpracovat, případně prostě uložit jako BLOB do DB. Jaký je přínos NoSQL DB?

    K článku. Chápu to správně tak, že pro každý typ dotazu si musím vytvořit (naprogramovat) pohled?
    28.1.2010 15:37 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    To v CouchDB skutečně musíte – nebo vyrobit nějaký chytrý pohled použitelný pro víc typů dotazů (ala zmíněné Megaview). Filozoficky jsou pohledy v CouchDB někde mezi dotazy, materializovanými pohledy a indexy z SQL databází :-)
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    29.1.2010 00:14 balki
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Cize problem sa spracovania sa presuva, dobre rozumiem ?

    Pri klasickych relacnych databazach prevazuje predspracovanie. (Da sa robit za behu, ale trpi vykon)

    V couchDB to spracovanie robi predovsetkym "za behu", pricom databaza je na taketo srandy optimalizovana. Je to pomalsie, ako uplne strukturovanymi datami ale nie az take katastrofalne ...

    Tak to je ?
    29.1.2010 09:19 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Spíš naopak, v relačních databázích se data obvykle "dolují" ze struktury v době čtení, tedy při vyhodnocování dotazu, zatímco v těch nerelačních je běžné rovnou ukládat data, která bude později potřeba přečíst. Tedy denormalizace je zde úplně normální, zatímco v relačních databázích se k ní přistupuje až když trpí výkon.

    Dokumentové databáze (CouchDB, MongoDB) mají nějaké prostředky k omezení té denormalizace (MapReduce, "normální" indexy a dotazy), ale třeba v key-value úložištích (já tomu česky říkám spíš persistentní mapy) už to jinak nejde.

    To klíčové jste ale vystihl: zpracování dat se přesouvá jinam.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    28.1.2010 20:21 jimik
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    tesim sa na pokracovanie ;-)
    29.1.2010 10:27 qwertzuiop
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    O (relačních) databázích a SQL vím jen trochu, nejsem žádný odborník.

    Pokud tomu rozumím správně, mezi položkami této DB neexistují vztahy ve smyslu, že části jedné položky mohou být v jiných položkách. Tedy: v relační DB bychom měli tabulku autorů, tabulku knih a tabulku žánrů; položka (např. kniha s informacemi o ní) by vznikla, kdybychom vzali z tabulky knihu a pomocí nějakých vztahů s jinými tabulkami vytvořili jednotku "kniha + autor + žánr".

    V této DB to, předpokládám, chodí tak, že položky není při výběru potřeba pomocí nějakých vztahů vytvářet z částí, stačí je získat pouze pomocí ID. Jinými slovy, v této DB se duplikují data, protože každá položka má všechny údaje "v sobě" a například změna názvu žánru by znamenala změnu všech položek.

    Jestli tomu je tak, je tato DB asi výhodná ve chvíli, kdy se ukládají nesouvisející položky (dokumenty, například poznámky v programu Tomboy, jak je patrno z odkazu Desktopcouch), ale nevýhodná ve chvíli, kdy bychom chtěli třeba udělat světovou DB všech knih, autorů a žánrů, protože by se to prostě špatně spravovalo (duplicity, absence schématu, které by bylo v daném případě zcela jednoznačné).

    Může mi moje domněnky někdo potvrdit, nebo mě vyvést z omylu?
    29.1.2010 10:36 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Myslím, že v zásadě už jsem tady v diskusi odpověděl, takže řeknu ještě tohle: jsou samozřejmě situace, kdy máte související informace uložené ve dvou nebo více dokumentech. Jak se tohle řeší bude ve druhém dílu.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    29.1.2010 10:46 qwertzuiop
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    No, tady se baví hlavně lidé, co s databázemi umí, takže jsem tomu moc neporozuměl. Takže, lze alespoň formou ano/ne potvrdit platnost mého 2. a 3. odstavce?
    29.1.2010 11:10 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Tak já to zkusím: intuitivně na to jdete správně, ale není to úplně přesné. V SQL databázi je základní jednotkou tabulka (s předem daným počtem a typem sloupců), v dokumentové databázi obecný dokument (obvykle JSON) bez předem dané struktury. Už to může rozhodovat, která databáze je kdy vhodnější.

    Když máte vysoce strukturovaná data, když se struktura moc často nemění, když je důležité transakční zpracování, nebo když prostě "potřebujete" nějakou vlastnost SQL databází, použijte je. Když máte data v podobě dokumentů (třeba ty poznámky v Tomboyi, ale klidně i složitější), jejichž struktura je předem nejasná nebo se často mění, můžete použít dokumentovou databázi.

    Dokumenty nemusí obsahovat všechna data v sobě, ale obvykle je různých typů dokumentů méně než tabulek v odpovídající SQL databázi (třeba ta situace kniha + žánry by vedla hned na 3 tabulky). Když budu mít autora v jednom dokumentu a každou jeho knihu v dalším dokumentu, není problém je získat najednou (bude v tom příštím dílu).

    Doufám, že je to srozumitelnější :-)
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    29.1.2010 12:19
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Napriklad dokumentove-orientovana databaze Riak ma neco jako relace mezi jinymi dokumenty. Nazyvaji to link.
    okbob avatar 29.1.2010 10:52 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    plus minus to tak je.

    Představte si to asi tak, že máte doma skříň na věci. Uvnitř skříně můžete mít buďto chaos - hromadu krabic s nějakým obsahem - co je v krabicích nevíte - maximálně máte štítek na krabici. Věci dáváte do skříní po krabicích, a vyndaváte po krabicích. Pokud vždy potřebujete obsah krabice, tak je to super. Popadnete celou krabici. Problém je, když hledáte něco, co úplně přesně nevíte, kde je. Pak musíte rozbalit každou krabici. Takhle zhruba fungují NoSQL databáze.

    Také můžete mít skříň plnou polic, a v každé polici pouze určité věci. Při hledání víte, kam se podívat. Na druhou stranu, musíte vymyslet systém, pokud dostáváte věci k uklízení po krabicích, tak potřebujete určitý čas, k tomu, abyste roztřídil obsah krabice, a totéž, pokud po Vás někdo bude chtít krabici s něčím, tak potřebujete čas, abyste dohledal a naplnil obsah krabice. Pokud potřebujete zjistit obsah jedné police, tak super. Nic Vás nezdržuje. To je zhruba přístup relačních databází.

    29.1.2010 11:56 osvc01
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    ten priklad s tou skrini je fantasticky a uz nyni vidim, jak to muzeme dal rozvinout, abychom presne dokazali ukazat na problematiku uschovavani dat.

    - prvni problem rel. databazi je mozno videt v nasledujicim:

    vidime, ze ten truhlar (databazovy analytik) k tomu, aby mohl udelat tu skrin spravne musi 'bohuzel' predtim, nez zacne rezat znat pokud mozno obsahy vsech krabic, ktere budou 'rozlozene' ukladany do skrine. Jeste vetsi problem nastava, kdyz se pote co byla skrin udelana zjisti, ze obsahy krabic prece jen meni. (firma zmenila strukturu sve cinosti, doslo k posunu na trhu ..).
    okbob avatar 29.1.2010 12:59 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Stejně tak jak v životě - kupujete nové skříně a prodáváte staré.
    30.1.2010 18:14 qwertzuiop
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Díky všem za vysvětlení.
    29.1.2010 11:38 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Nemyslel jste místo idempotentní spíše čistá?
    29.1.2010 12:11 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)
    Idempotentní a čistá a referenčně transparentní a já nevím co všechno :-) Může být, že mám tu terminologii špatně – funkcionální teorii nemám úplně zmáknutou.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    29.1.2010 12:47 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Lehký úvod do CouchDB – 1 (základní API)

    Osobně si nemyslím, že je to totéž. Ve Wikipedii říkají

    invoking the procedure a single time or multiple times has the same result; i.e., after any number of method calls all variables have the same value as they did after the first call

    a podle mne tím myslí f(f(x))=f(x) případně u procedur, co nic nevrací tím myslí, že se stav světa nezmění po 2., 3. a dalších voláních (například zruším objednávku).

    Zato referenční transparentnost znamená, že výraz mohu nahradit jeho výsledkem, tedy u procedur to znamená, že je nemusím vůbec volat, protože nic nevrací -- idempotentní procedury mohou mít side-effect, ale referenčně transparentní ne (čistě funkcionální jazyky nemají procedury).

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.