Kouhei Sutou
null+****@clear*****
Fri Feb 28 16:16:43 JST 2014
Kouhei Sutou 2014-02-28 16:16:43 +0900 (Fri, 28 Feb 2014) New Revision: 69c7f0f8fc3c42599fb52d9cab93c3e9a35deb4f https://github.com/droonga/droonga.org/commit/69c7f0f8fc3c42599fb52d9cab93c3e9a35deb4f Message: tutorial handler: confirm workable Modified files: _po/ja/tutorial/plugin-development/handler/index.po ja/tutorial/plugin-development/handler/index.md tutorial/plugin-development/handler/index.md Modified: _po/ja/tutorial/plugin-development/handler/index.po (+31 -20) =================================================================== --- _po/ja/tutorial/plugin-development/handler/index.po 2014-02-28 16:07:05 +0900 (f71a639) +++ _po/ja/tutorial/plugin-development/handler/index.po 2014-02-28 16:16:43 +0900 (d68039a) @@ -9,7 +9,8 @@ msgstr "" msgid "" "---\n" -"title: \"Plugin: Handle requests on all partitions\"\n" +"title: \"Plugin: Handle requests on all partitions, to add a new command workin" +"g around the storage\"\n" "layout: en\n" "---" msgstr "" @@ -24,7 +25,9 @@ msgstr "## チュートリアルのゴール" msgid "" "This tutorial aims to help you to learn how to develop plugins which do someth" -"ing dispersively for/in each partition, around the handling phase." +"ing dispersively for/in each partition, around the handling phase.\n" +"In other words, this tutorial describes *how to add a new simple command to th" +"e Droonga Engine*." msgstr "" msgid "## Precondition" @@ -33,32 +36,32 @@ msgstr "## 前提条件" msgid "* You must complete the [tutorial for the adaption phase][adapter]." msgstr "" -msgid "## Handling of incoming messages" +msgid "## Handling of requests" msgstr "" msgid "" -"When an incoming message is transferred from the adaption phase, the Droonga E" -"ngine enters into the *processing phase*." +"When a request is transferred from the adaption phase, the Droonga Engine ente" +"rs into the *processing phase*." msgstr "" msgid "" -"In the processing phase, the Droonga Engine processes incoming messages step b" -"y step.\n" +"In the processing phase, the Droonga Engine processes the request step by step" +".\n" "One *step* is constructed from some sub phases: *planning phase*, *distributio" "n phase*, *handling phase*, and *collection phase*." msgstr "" msgid "" " * At the *planning phase*, the Droonga Engine generates multiple sub steps to" -" process an incoming message.\n" +" process the request.\n" " In simple cases, you don't have to write codes for this phase, then there i" -"s just one sub step to handle the message.\n" -" * At the *distribution phase*, the Droonga Engine distributes the message to " -"multiple partitions.\n" +"s just one sub step to handle the request.\n" +" * At the *distribution phase*, the Droonga Engine distributes task messages f" +"or the request, to multiple partitions.\n" " (It is completely done by the Droonga Engine itself, so this phase is not p" "luggable.)\n" " * At the *handling phase*, *each partition simply processes only one distribu" -"ted message as its input, and returns a result.*\n" +"ted task message as its input, and returns a result.*\n" " This is the time that actual storage accesses happen.\n" " Actually, some commands (`search`, `add`, `create_table` and so on) access " "to the storage at the time.\n" @@ -271,13 +274,13 @@ msgstr "" msgid "" "~~~ruby\n" -"(snip)\n" +"# (snip)\n" " define_single_step do |step|\n" " step.name = \"countRecords\"\n" " step.handler = :Handler\n" " step.collector = Collectors::Sum\n" " end\n" -"(snip)\n" +"# (snip)\n" "~~~" msgstr "" @@ -337,7 +340,11 @@ msgid "" " \"inReplyTo\": \"1392621168.0119512\",\n" " \"statusCode\": 200,\n" " \"type\": \"countRecords.result\",\n" -" \"body\": [0, 0, 0]\n" +" \"body\": [\n" +" 0,\n" +" 0,\n" +" 0\n" +" ]\n" " }\n" "]\n" "~~~" @@ -385,17 +392,17 @@ msgstr "" msgid "" "~~~ruby\n" -"(snip)\n" +"# (snip)\n" " class Handler < Droonga::Handler\n" " def handle(message)\n" " request = message.request\n" -" table_name = request[\"body\"][\"table\"]\n" +" table_name = request[\"table\"]\n" " table = @context[table_name]\n" " count = table.size\n" " [count]\n" " end\n" " end\n" -"(snip)\n" +"# (snip)\n" "~~~" msgstr "" @@ -435,13 +442,17 @@ msgid "" " \"inReplyTo\": \"1392621168.0119512\",\n" " \"statusCode\": 200,\n" " \"type\": \"countRecords.result\",\n" -" \"body\": [12, 12, 11]\n" +" \"body\": [\n" +" 14,\n" +" 15,\n" +" 11\n" +" ]\n" " }\n" "]\n" "~~~" msgstr "" -msgid "Because there are totally 35 records, they are stored evenly like above." +msgid "Because there are totally 40 records, they are stored evenly like above." msgstr "" msgid "## Design a read-write command `deleteStores`" Modified: ja/tutorial/plugin-development/handler/index.md (+25 -22) =================================================================== --- ja/tutorial/plugin-development/handler/index.md 2014-02-28 16:07:05 +0900 (9faa2cc) +++ ja/tutorial/plugin-development/handler/index.md 2014-02-28 16:16:43 +0900 (1809ece) @@ -1,5 +1,5 @@ --- -title: "Plugin: Handle requests on all partitions" +title: "Plugin: Handle requests on all partitions, to add a new command working around the storage" layout: en --- @@ -18,23 +18,24 @@ layout: en ## チュートリアルのゴール This tutorial aims to help you to learn how to develop plugins which do something dispersively for/in each partition, around the handling phase. +In other words, this tutorial describes *how to add a new simple command to the Droonga Engine*. ## 前提条件 * You must complete the [tutorial for the adaption phase][adapter]. -## Handling of incoming messages +## Handling of requests -When an incoming message is transferred from the adaption phase, the Droonga Engine enters into the *processing phase*. +When a request is transferred from the adaption phase, the Droonga Engine enters into the *processing phase*. -In the processing phase, the Droonga Engine processes incoming messages step by step. +In the processing phase, the Droonga Engine processes the request step by step. One *step* is constructed from some sub phases: *planning phase*, *distribution phase*, *handling phase*, and *collection phase*. - * At the *planning phase*, the Droonga Engine generates multiple sub steps to process an incoming message. - In simple cases, you don't have to write codes for this phase, then there is just one sub step to handle the message. - * At the *distribution phase*, the Droonga Engine distributes the message to multiple partitions. + * At the *planning phase*, the Droonga Engine generates multiple sub steps to process the request. + In simple cases, you don't have to write codes for this phase, then there is just one sub step to handle the request. + * At the *distribution phase*, the Droonga Engine distributes task messages for the request, to multiple partitions. (It is completely done by the Droonga Engine itself, so this phase is not pluggable.) - * At the *handling phase*, *each partition simply processes only one distributed message as its input, and returns a result.* + * At the *handling phase*, *each partition simply processes only one distributed task message as its input, and returns a result.* This is the time that actual storage accesses happen. Actually, some commands (`search`, `add`, `create_table` and so on) access to the storage at the time. * At the *collection phase*, the Droonga Engine collects results from partitions to one unified result. @@ -198,13 +199,13 @@ Then, we also have to bind a collector to the step, with the configuration `step lib/droonga/plugins/count-records.rb: ~~~ruby -(snip) +# (snip) define_single_step do |step| step.name = "countRecords" step.handler = :Handler step.collector = Collectors::Sum end -(snip) +# (snip) ~~~ The `Collectors::Sum` is one of built-in collectors. @@ -245,7 +246,11 @@ Elapsed time: 0.01494 "inReplyTo": "1392621168.0119512", "statusCode": 200, "type": "countRecords.result", - "body": [0, 0, 0] + "body": [ + 0, + 0, + 0 + ] } ] ~~~ @@ -276,17 +281,17 @@ Let's implement codes to count up the number of records from the actual storage. lib/droonga/plugins/count-records.rb: ~~~ruby -(snip) +# (snip) class Handler < Droonga::Handler def handle(message) request = message.request - table_name = request["body"]["table"] + table_name = request["table"] table = @context[table_name] count = table.size [count] end end -(snip) +# (snip) ~~~ Look at the argument of the `handle` method. @@ -314,18 +319,16 @@ Elapsed time: 0.01494 "inReplyTo": "1392621168.0119512", "statusCode": 200, "type": "countRecords.result", - "body": [12, 12, 11] + "body": [ + 14, + 15, + 11 + ] } ] ~~~ -Because there are totally 35 records, they are stored evenly like above. - - - - - - +Because there are totally 40 records, they are stored evenly like above. ## Design a read-write command `deleteStores` Modified: tutorial/plugin-development/handler/index.md (+16 -14) =================================================================== --- tutorial/plugin-development/handler/index.md 2014-02-28 16:07:05 +0900 (a624d1a) +++ tutorial/plugin-development/handler/index.md 2014-02-28 16:16:43 +0900 (a6f6ce5) @@ -190,13 +190,13 @@ Then, we also have to bind a collector to the step, with the configuration `step lib/droonga/plugins/count-records.rb: ~~~ruby -(snip) +# (snip) define_single_step do |step| step.name = "countRecords" step.handler = :Handler step.collector = Collectors::Sum end -(snip) +# (snip) ~~~ The `Collectors::Sum` is one of built-in collectors. @@ -237,7 +237,11 @@ Elapsed time: 0.01494 "inReplyTo": "1392621168.0119512", "statusCode": 200, "type": "countRecords.result", - "body": [0, 0, 0] + "body": [ + 0, + 0, + 0 + ] } ] ~~~ @@ -268,17 +272,17 @@ Let's implement codes to count up the number of records from the actual storage. lib/droonga/plugins/count-records.rb: ~~~ruby -(snip) +# (snip) class Handler < Droonga::Handler def handle(message) request = message.request - table_name = request["body"]["table"] + table_name = request["table"] table = @context[table_name] count = table.size [count] end end -(snip) +# (snip) ~~~ Look at the argument of the `handle` method. @@ -306,18 +310,16 @@ Elapsed time: 0.01494 "inReplyTo": "1392621168.0119512", "statusCode": 200, "type": "countRecords.result", - "body": [12, 12, 11] + "body": [ + 14, + 15, + 11 + ] } ] ~~~ -Because there are totally 35 records, they are stored evenly like above. - - - - - - +Because there are totally 40 records, they are stored evenly like above. ## Design a read-write command `deleteStores` -------------- next part -------------- HTML����������������������������...Download