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:22 | Zajímavý projekt

Byl spuštěn Humble Dystopian Bundle. V balíčku počítačových her jsou také hry běžící na Linuxu: Beholder, Orwell: Keeping an Eye On You, Orwell: Ignorance is Strength a Observer.

Ladislav Hagara | Komentářů: 0
včera 22:44 | Zajímavý článek

Jan Klat publikoval na Medium výsledky ankety věnované platům PHP vývojářů. Zúčastnilo se 419 respondentů. Kompletní výsledky na Tabulky Google.

Ladislav Hagara | Komentářů: 1
včera 22:22 | Nová verze

Byla vydána nová verze 1.29 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Představení novinek také na YouTube.

Ladislav Hagara | Komentářů: 0
včera 11:47 | Pozvánky
Začínáte s automatizací? Chcete se naučit správně používat Ansible? Přijďte na další Prague Containers Meetup 20. listopadu v prostorách Seznamu v Praze na Andělu.
little-drunk-jesus | Komentářů: 0
včera 11:47 | Pozvánky
V úterý 20. 11. v Praze proběhne akce Oracle Czech Republic Meetup Group. Od 18.00 si budete moct vyslechnout přednášky NetSuite Developer Toolset a Product Recommendations system at Bronto.
RichardF | Komentářů: 0
včera 10:33 | Nová verze

Byly aktualizovány živé instalační obrazy průběžně aktualizované linuxové distribuce Void Linux (Wikipedie). Nejnovější obrazy ve verzi 20181111 jsou k dispozici vedle i686 a x86_64 také pro jednodeskové počítače s ARM: BeagleBone, Cubieboard, Odroid a Raspberry Pi. Void Linux používá balíčkovací systém XBPS (X Binary Package System), LibreSSL a init systém a správce služeb runit. Ke stažení jsou obrazy postavené jak nad glibc, tak nad musl.

Ladislav Hagara | Komentářů: 3
včera 02:00 | IT novinky

Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává superpočítač Summit. Český superpočítač Salomon klesl na 213. místo. Další přehledy a statistiky na stránkách projektu. V aktuálním žebříčku GREEN500 (GFlops/watts) obsadil superpočítač Summit 3. místo.

Ladislav Hagara | Komentářů: 0
12.11. 22:55 | Zajímavý projekt

Sir Tim Berners-Lee koncem září představil myšlenku projektu Solid. Jedná se o reakci na jednak jednostranné využívání webu k neinteraktivnímu publikování dokumentů, ale také centralizaci služeb, v jejichž případě uživatelé předávají svá data několika málo centrálním entitám. Článek na webu LWN.net Solid ukazuje konkrétněji. Základním konceptem je „pod“, uzel (lokální nebo v cloudu), kde by uživatelé mohli ukládat své komentáře k obsahu třetích stran.

Fluttershy, yay! | Komentářů: 0
11.11. 02:00 | IT novinky

S představením jednodeskového počítače Raspberry Pi 3 Model B+ v březnu letošního roku byla představena také rozšiřující deska Raspberry Pi PoE HAT (Power over Ethernet Hardware Attached on Top). Koupit ji bylo možné ale až v srpnu. Krátce na to se uživatelé začali stěžovat, že jim nefungují některá zařízení připojena k Raspberry Pi. Po potvrzení problému - nedostatečné napájení - byla rozšiřující deska stažena z prodeje. Nadace Raspberry Pi se omlouvá a informuje, že problém byl vyřešen a nová opravená verze desky je opět v prodeji.

Ladislav Hagara | Komentářů: 0
10.11. 19:55 | Komunita

Nadace pro svobodný software (FSF) aktualizovala své stránky věnované softwarovým licencím. Mezi nesvobodné licence byla například přidána licence Commons Clause. Ta zakazuje komerční použití, viz zprávička Společnost Redis Labs přelicencovala své rozšiřující moduly databáze Redis z GNU AGPL na Apache s Commons Clause a fork těchto modulů GoodFORM (Free and Open Redis Modules).

Ladislav Hagara | Komentářů: 0
Jak nejčastěji otevíráte dokumenty na počítači?
 (89%)
 (3%)
 (8%)
Celkem 62 hlasů
 Komentářů: 4, poslední včera 14:36
Rozcestník

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

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

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.