From f12e71d8b7d263cd2ea0f6151af2220c9c4bf04b Mon Sep 17 00:00:00 2001 From: Evgeniy Osintsev Date: Thu, 4 Aug 2022 14:45:36 +0400 Subject: [PATCH] Correct description of applying data schema on the Code tab in the schema.yml file Fixes #3053 --- doc/book/box/data_model.rst | 92 ++++++++++---------- doc/getting_started/getting_started_imcp.rst | 22 ++--- 2 files changed, 57 insertions(+), 57 deletions(-) diff --git a/doc/book/box/data_model.rst b/doc/book/box/data_model.rst index cf9d90153c..4569a1ed40 100644 --- a/doc/book/box/data_model.rst +++ b/doc/book/box/data_model.rst @@ -451,7 +451,7 @@ Full information is in section - :ref:`decimal ` - TREE or HASH * - ``'string'`` (may also be called ``'str'``) - - :ref:`string ` + - :ref:`string ` - TREE, BITSET, or HASH * - ``'varbinary'`` - :ref:`varbinary ` @@ -467,22 +467,22 @@ Full information is in section - :ref:`RTREE ` * - ``'scalar'`` - may include :ref:`nil `, - :ref:`boolean `, - :ref:`integer `, - :ref:`unsigned `, - :ref:`number `, - :ref:`decimal `, - :ref:`string `, - :ref:`varbinary `, + :ref:`boolean `, + :ref:`integer `, + :ref:`unsigned `, + :ref:`number `, + :ref:`decimal `, + :ref:`string `, + :ref:`varbinary `, or :ref:`uuid ` values | |br| - When a scalar field contains values of - different underlying types, the key order - is: nils, then booleans, then numbers, - then strings, then varbinaries, then - uuids. + When a scalar field contains values of + different underlying types, the key order + is: nils, then booleans, then numbers, + then strings, then varbinaries, then + uuids. - TREE or HASH - + .. _index-collation: Collations @@ -1111,40 +1111,40 @@ resource usage of each function. * - Complexity factor - Effect * - Index size - - The number of index keys is the same as the number - of tuples in the data set. For a TREE index, if - there are more keys, then the lookup time will be - greater, although, of course, the effect is not - linear. For a HASH index, if there are more keys, - then there is more RAM used, but the number of - low-level steps tends to remain constant. + - The number of index keys is the same as the number + of tuples in the data set. For a TREE index, if + there are more keys, then the lookup time will be + greater, although, of course, the effect is not + linear. For a HASH index, if there are more keys, + then there is more RAM used, but the number of + low-level steps tends to remain constant. * - Index type - - Typically, a HASH index is faster than a TREE index - if the number of tuples in the space is greater - than one. + - Typically, a HASH index is faster than a TREE index + if the number of tuples in the space is greater + than one. * - Number of indexes accessed - - Ordinarily, only one index is accessed to retrieve - one tuple. But to update the tuple, there must be N - accesses if the space has N different indexes. - |br| - Note regarding storage engine: Vinyl optimizes away such - accesses if secondary index fields are unchanged by - the update. So, this complexity factor applies only to - memtx, since it always makes a full-tuple copy on every + - Ordinarily, only one index is accessed to retrieve + one tuple. But to update the tuple, there must be N + accesses if the space has N different indexes. + |br| + Note regarding storage engine: Vinyl optimizes away such + accesses if secondary index fields are unchanged by + the update. So, this complexity factor applies only to + memtx, since it always makes a full-tuple copy on every update. * - Number of tuples accessed - - A few requests, for example, SELECT, can retrieve - multiple tuples. This factor is usually less - important than the others. + - A few requests, for example, SELECT, can retrieve + multiple tuples. This factor is usually less + important than the others. * - WAL settings - - The important setting for the write-ahead log is - :ref:`wal_mode `. - If the setting causes no writing or - delayed writing, this factor is unimportant. If the - setting causes every data-change request to wait - for writing to finish on a slow device, this factor - is more important than all the others. - + - The important setting for the write-ahead log is + :ref:`wal_mode `. + If the setting causes no writing or + delayed writing, this factor is unimportant. If the + setting causes every data-change request to wait + for writing to finish on a slow device, this factor + is more important than all the others. + Data schema description ----------------------- @@ -1225,13 +1225,13 @@ The schema would look something like this: This alternative is simpler to use, and you do not have to dive deep into Lua. -``DDL`` is a built-in +``DDL`` is a built-in :doc:`Cartridge ` module. Cartridge is a cluster solution for Tarantool. In its WebUI, there is a separate tab -called "Schema". On this tab, you can define the schema, check its correctness, +called "Code". On this tab, in the ``schema.yml`` file, you can define the schema, check its correctness, and apply it to the whole cluster. -If you do not use Cartridge, you can still use the DDL module: +If you do not use Cartridge, you can still use the DDL module: put the following Lua code into the file that you use to run Tarantool. This file is usually called ``init.lua``. diff --git a/doc/getting_started/getting_started_imcp.rst b/doc/getting_started/getting_started_imcp.rst index 98c681fa63..2b83d60337 100644 --- a/doc/getting_started/getting_started_imcp.rst +++ b/doc/getting_started/getting_started_imcp.rst @@ -57,12 +57,12 @@ if you want to get better acquainted with it. cartridge build cartridge start - + .. note:: In case of a problem with `cartridge build`, run it with the `--verbose` flag to learn about the source of the problem. If there is a problem with Node.js (`npm`): - + 1. Check that Node.js is in the `$PATH`. 2. Try forcefully removing the `node_modules` directory from the dependencies' directories: @@ -154,9 +154,9 @@ located in the top right corner. Creating a data schema [2 minutes] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Let's start with the data schema -- take a look at the "Code" tab on the left. +Let's start with the data schema -- take a look at the **Code** tab on the left. -Here we can create a file called ``schema.yml``. In this file, you can +There you can find a file called ``schema.yml``. In this file, you can describe the entire cluster's data schema, edit the current schema, validate its correctness, and apply it to the whole cluster. @@ -168,8 +168,8 @@ We need to store: * Videos with descriptions * Likes for each video -Create a ``schema.yml`` file to load the schema into the cluster. -Copy and paste schema to this file. Click the "Apply" button. +Copy the schema description from the code block below and paste it in the ``schema.yml`` file on the **Code** tab. +Click the "Apply" button. After that, the data schema will be described in the cluster. This is what our data schema will look like: @@ -332,14 +332,14 @@ Paste the code below into ``api.lua`` and click "Apply". function like_video(request) local video_id = request:post_param("video_id") local user_id = request:post_param("user_id") - + local result, err = crud.insert_object('likes', {like_id = uuid.new(), video_id = uuid.fromstr(video_id), user_id = uuid.fromstr(user_id)}) if err ~= nil then return {body = json.encode({status = "Error!", error = err}), status = 500} end - + return {body = json.encode({status = "Success!", result = result}), status = 200} end @@ -365,7 +365,7 @@ Paste the configuration example below into ``config.yml`` and click "Apply". --- functions: - + add_user: module: extensions.api handler: add_user @@ -392,7 +392,7 @@ Done! Let's make test requests from the console. curl -X POST --data "fullname=Taran Tool" url/add_user .. note:: - + In the requests, substitute ``url`` with the address of your sandbox. The protocol must be strictly HTTP. @@ -448,7 +448,7 @@ Looking at the data [1 minute] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. note:: - + The following instructions are for Tarantool Enterprise Edition and the Try Tarantool cloud service. The Space-Explorer tool is unavailable in the open-source version. Use the console to view data.