rroonga 2.0.7-x86-mingw32 → 2.0.8-x86-mingw32

data/vendor/local/share/doc/groonga/ja/html/_sources/reference.txt

@@ -10,13 +10,13 @@
 
    reference/executables
    reference/output
-   reference/command_version
-   reference/commands
+   reference/command
    reference/type
    reference/tokenizers
+   reference/query_expanders
    reference/pseudo_column
    reference/grn_expr
-   reference/functions
+   reference/function
    reference/indexing
    reference/log
    reference/api

data/vendor/local/share/doc/groonga/ja/html/_sources/reference/command.txt

@@ -0,0 +1,20 @@
+.. -*- rst -*-
+
+.. highlightlang:: none
+
+Command
+=======
+
+Command is the most important processing unit in query API. You
+request a processing to groonga by a command.
+
+This section describes about command and built-in commands.
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+
+   command/command_version
+   command/output_format
+   command/return_code
+   commands/*

data/vendor/local/share/doc/groonga/ja/html/_sources/reference/command/output_format.txt

@@ -0,0 +1,228 @@
+.. -*- rst -*-
+
+.. highlightlang:: none
+
+Output format
+=============
+
+Summary
+-------
+
+Commands output their result as JSON, MessagePack, XML or TSV format.
+
+JSON and MessagePack output have the same structure. XML and TSV are
+their original structure.
+
+JSON or MessagePack is recommend format. XML is useful for visual
+result check. TSV is just for special use. Normally you doesn't need
+to use TSV.
+
+JSON and MessagePack
+--------------------
+
+This secsion describes the structure of command result on JSON and
+MessagePack format. JSON is used to show structure because MessagePack
+is binary format. Binary format isn't proper for documenataion.
+
+JSON and MessagePack uses the following structure::
+
+  [HEADER, BODY]
+
+For example::
+
+  [
+    [
+      0,
+      1337566253.89858,
+      0.000355720520019531
+    ],
+    [
+      [
+        [
+          1
+        ],
+        [
+          [
+            "_id",
+            "UInt32"
+          ],
+          [
+            "_key",
+            "ShortText"
+          ],
+          [
+            "content",
+            "Text"
+          ],
+          [
+            "n_likes",
+            "UInt32"
+          ]
+        ],
+        [
+          2,
+          "Groonga",
+          "I started to use groonga. It's very fast!",
+          10
+        ]
+      ]
+    ]
+  ]
+
+In the example, the following part is ``HEADER``::
+
+  [
+    0,
+    1337566253.89858,
+    0.000355720520019531
+  ]
+
+The following part is ``BODY``::
+
+  [
+    [
+      [
+        1
+      ],
+      [
+        [
+          "_id",
+          "UInt32"
+        ],
+        [
+          "_key",
+          "ShortText"
+        ],
+        [
+          "content",
+          "Text"
+        ],
+        [
+          "n_likes",
+          "UInt32"
+        ]
+      ],
+      [
+        2,
+        "Groonga",
+        "I started to use groonga. It's very fast!",
+        10
+      ]
+    ]
+  ]
+
+``HEADER``
+^^^^^^^^^^
+
+``HEADER`` is an array. The content of ``HEADER`` has some patterns.
+
+Success case
+++++++++++++
+
+``HEADER`` has three elements on success::
+
+  [0, UNIX_TIME_WHEN_COMMAND_IS_STARTED, ELAPSED_TIME]
+
+The first element is always ``0``.
+
+``UNIX_TIME_WHEN_COMMAND_IS_STARTED`` is the number of seconds
+since 1970-01-01 00:00:00 UTC when the command is started
+processing. ``ELAPSED_TIME`` is the elapsed time for processing the
+command in seconds. Both ``UNIX_TIME_WHEN_COMMAND_IS_STARTED`` and
+``ELAPSED_TIME`` are float value. The precision of them are
+nanosecond.
+
+Error case
+++++++++++
+
+``HEADER`` has four or five elements on error::
+
+  [
+    RETURN_CODE,
+    UNIX_TIME_WHEN_COMMAND_IS_STARTED,
+    ELAPSED_TIME,
+    ERROR_MESSAGE,
+    ERROR_LOCATION
+  ]
+
+``ERROR_LOCATION`` may not be included in ``HEADER`` but other four
+elements are always included.
+
+``RETURN_CODE`` is non 0 value. See :doc:`return_code` about available
+return codes.
+
+``UNIX_TIME_WHEN_COMMAND_IS_STARTED`` and ``ELAPSED_TIME`` are the
+same as success case.
+
+``ERROR_MESSAGE`` is an error message in string.
+
+``ERROR_LOCATION`` is optional. If error location is collected,
+``ERROR_LOCATION`` is included. ``ERROR_LOCATION`` is an
+array. ``ERROR_LOCATION`` has one ore two elements::
+
+  [
+    LOCATION_IN_GROONGA,
+    LOCATION_IN_INPUT
+  ]
+
+``LOCATION_IN_GROONGA`` is the source location that error is occurred
+in groonga. It is useful for groonga developers but not useful for
+users. ``LOCATION_IN_GROONGA`` is an array. ``LOCATION_IN_GROONGA`` has
+three elements::
+
+  [
+    FUNCTION_NAME,
+    SOURCE_FILE_NAME,
+    LINE_NUMBER
+  ]
+
+``FUNCTION_NAME`` is the name of function that error is occurred.
+
+``SOURCE_FILE_NAME`` is the name of groonga's source file that error is
+occurred.
+
+``LINE_NUMBER`` is the line number of ``SOURCE_FILE_NAME`` that error
+is occurred.
+
+``LOCATION_IN_INPUT`` is optional. ``LOCATION_IN_INPUT`` is included
+when the location that error is occurred in input file is
+collected. Input file can be specified by ``--file`` command line
+option for ``groonga`` command. ``LOCATION_IN_GROONGA`` is an
+array. ``LOCATION_IN_GROONGA`` has three elements::
+
+  [
+    INPUT_FILE_NAME,
+    LINE_NUMBER,
+    LINE_CONTENT
+  ]
+
+``INPUT_FILE_NAME`` is the input file name that error is occurred.
+
+``LINE_NUMBER`` is the line number of ``INPUT_FILE_NAME`` that error
+is occurred.
+
+``LINE_CONTENT`` is the content at ``LINE_NUMBER`` in
+``INPUT_FILE_NAME``.
+
+``BODY``
+^^^^^^^^
+
+``BODY`` content depends on the executed command. It may be omitted.
+
+``BODY`` may be an error message on error case.
+
+XML
+---
+
+TODO
+
+TSV
+---
+
+TODO
+
+See also
+--------
+
+* :doc:`return_code` describes about return code.
+

data/vendor/local/share/doc/groonga/ja/html/_sources/reference/command/return_code.txt

@@ -0,0 +1,110 @@
+.. -*- rst -*-
+
+.. highlightlang:: none
+
+Return code
+===========
+
+Summary
+-------
+
+Return code is used to show whether a processing is succeeded or
+not. If the processing is not succeeded, return code shows error type.
+
+Return code is used in C API and query API. You can check return code
+via ``grn_ctx_t::rc`` in C API. You can check return code by looking
+the header element in query API. See :doc:`output_format` about the
+header element in query API.
+
+List
+----
+
+Here is a list of return codes. ``GRN_SUCCESS`` (= 0) means that the
+processing is succeeded. Return codes that have negative value show
+error type. ``GRN_END_OF_DATA`` is a special return code. It is used
+only C API. It is not showen in query API.
+
+* 0: ``GRN_SUCCESS``
+* 1: ``GRN_END_OF_DATA``
+* -1: ``GRN_UNKNOWN_ERROR``
+* -2: ``GRN_OPERATION_NOT_PERMITTED``
+* -3: ``GRN_NO_SUCH_FILE_OR_DIRECTORY``
+* -4: ``GRN_NO_SUCH_PROCESS``
+* -5: ``GRN_INTERRUPTED_FUNCTION_CALL``
+* -6: ``GRN_INPUT_OUTPUT_ERROR``
+* -7: ``GRN_NO_SUCH_DEVICE_OR_ADDRESS``
+* -8: ``GRN_ARG_LIST_TOO_LONG``
+* -9: ``GRN_EXEC_FORMAT_ERROR``
+* -10: ``GRN_BAD_FILE_DESCRIPTOR``
+* -11: ``GRN_NO_CHILD_PROCESSES``
+* -12: ``GRN_RESOURCE_TEMPORARILY_UNAVAILABLE``
+* -13: ``GRN_NOT_ENOUGH_SPACE``
+* -14: ``GRN_PERMISSION_DENIED``
+* -15: ``GRN_BAD_ADDRESS``
+* -16: ``GRN_RESOURCE_BUSY``
+* -17: ``GRN_FILE_EXISTS``
+* -18: ``GRN_IMPROPER_LINK``
+* -19: ``GRN_NO_SUCH_DEVICE``
+* -20: ``GRN_NOT_A_DIRECTORY``
+* -21: ``GRN_IS_A_DIRECTORY``
+* -22: ``GRN_INVALID_ARGUMENT``
+* -23: ``GRN_TOO_MANY_OPEN_FILES_IN_SYSTEM``
+* -24: ``GRN_TOO_MANY_OPEN_FILES``
+* -25: ``GRN_INAPPROPRIATE_I_O_CONTROL_OPERATION``
+* -26: ``GRN_FILE_TOO_LARGE``
+* -27: ``GRN_NO_SPACE_LEFT_ON_DEVICE``
+* -28: ``GRN_INVALID_SEEK``
+* -29: ``GRN_READ_ONLY_FILE_SYSTEM``
+* -30: ``GRN_TOO_MANY_LINKS``
+* -31: ``GRN_BROKEN_PIPE``
+* -32: ``GRN_DOMAIN_ERROR``
+* -33: ``GRN_RESULT_TOO_LARGE``
+* -34: ``GRN_RESOURCE_DEADLOCK_AVOIDED``
+* -35: ``GRN_NO_MEMORY_AVAILABLE``
+* -36: ``GRN_FILENAME_TOO_LONG``
+* -37: ``GRN_NO_LOCKS_AVAILABLE``
+* -38: ``GRN_FUNCTION_NOT_IMPLEMENTED``
+* -39: ``GRN_DIRECTORY_NOT_EMPTY``
+* -40: ``GRN_ILLEGAL_BYTE_SEQUENCE``
+* -41: ``GRN_SOCKET_NOT_INITIALIZED``
+* -42: ``GRN_OPERATION_WOULD_BLOCK``
+* -43: ``GRN_ADDRESS_IS_NOT_AVAILABLE``
+* -44: ``GRN_NETWORK_IS_DOWN``
+* -45: ``GRN_NO_BUFFER``
+* -46: ``GRN_SOCKET_IS_ALREADY_CONNECTED``
+* -47: ``GRN_SOCKET_IS_NOT_CONNECTED``
+* -48: ``GRN_SOCKET_IS_ALREADY_SHUTDOWNED``
+* -49: ``GRN_OPERATION_TIMEOUT``
+* -50: ``GRN_CONNECTION_REFUSED``
+* -51: ``GRN_RANGE_ERROR``
+* -52: ``GRN_TOKENIZER_ERROR``
+* -53: ``GRN_FILE_CORRUPT``
+* -54: ``GRN_INVALID_FORMAT``
+* -55: ``GRN_OBJECT_CORRUPT``
+* -56: ``GRN_TOO_MANY_SYMBOLIC_LINKS``
+* -57: ``GRN_NOT_SOCKET``
+* -58: ``GRN_OPERATION_NOT_SUPPORTED``
+* -59: ``GRN_ADDRESS_IS_IN_USE``
+* -60: ``GRN_ZLIB_ERROR``
+* -61: ``GRN_LZO_ERROR``
+* -62: ``GRN_STACK_OVER_FLOW``
+* -63: ``GRN_SYNTAX_ERROR``
+* -64: ``GRN_RETRY_MAX``
+* -65: ``GRN_INCOMPATIBLE_FILE_FORMAT``
+* -66: ``GRN_UPDATE_NOT_ALLOWED``
+* -67: ``GRN_TOO_SMALL_OFFSET``
+* -68: ``GRN_TOO_LARGE_OFFSET``
+* -69: ``GRN_TOO_SMALL_LIMIT``
+* -70: ``GRN_CAS_ERROR``
+* -71: ``GRN_UNSUPPORTED_COMMAND_VERSION``
+
+See also
+--------
+
+* :doc:`output_format` shows where return code is appeared in query
+  API response.
+* :doc:`/spec/gqtp`: GQTP protocol also uses return code as status but
+  it uses 2byte unsigned integer. So return codes that have negative
+  value are statuses that have positive value in GQTP protocol. You
+  can convert status value in GQTP protocol to return code by
+  handling it as 2byte signed integer.

data/vendor/local/share/doc/groonga/ja/html/_sources/reference/commands/register.txt

@@ -0,0 +1,59 @@
+.. -*- rst -*-
+
+.. highlightlang:: none
+
+.. groonga-command
+.. database: commands_register
+
+register
+========
+
+Summary
+-------
+
+``register`` command registers a plugin. You need to register a plugin
+before you use a plugin.
+
+You need just one ``register`` command for a plugin in the same
+database because registered plugin information is written into the
+database.  When you restart your ``groonga`` process, ``groonga``
+process loads all registered plugins without ``register`` command.
+
+.. note::
+
+   Registered plugins can't be removed for now.
+
+Syntax
+------
+
+``register`` has a parameter ``path``. It is required parameter::
+
+  register path
+
+Usage
+-----
+
+Here is a sample that registers ``QueryExpanderTSV`` query expander
+that is included in
+``${PREFIX}/lib/groonga/plugins/query_expanders/tsv.so``.
+
+.. groonga-command
+.. include:: ../../example/reference/commands/register/query_expanders_tsv.log
+.. register query_expanders/tsv
+
+You can omit ``${PREFIX}/lib/groonga/plugins/`` and suffix (``.so``).
+They are completed automatically.
+
+You can specify absolute path such as ``register
+/usr/lib/groonga/plugins/query_expanders/tsv.so``.
+
+Return value
+------------
+
+``register`` returns ``true`` as body on success such as::
+
+  [HEADER, true]
+
+If ``register`` fails, error details are in ``HEADER``.
+
+See :doc:`/reference/command/output_format` for ``HEADER``.

data/vendor/local/share/doc/groonga/ja/html/_sources/reference/commands/select.txt

@@ -442,6 +442,8 @@ storategy escalation is not used because the number of matched
 records (0) is larger than ``match_escalation_threshold`` (-1). So no
 more searches aren't executed. And no records are matched.
 
+.. _query-expansion:
+
 ``query_expansion``
 """""""""""""""""""