7.3.38. logical_table_remove — Groonga v14.0.9ドキュメント

Skip to main content
`Ctrl`+`K`

# 7.3.38. `logical_table_remove`

## 7.3.38.1. 概要

Added in version 5.0.5.

`logical_table_remove` は指定した論理テーブルのテーブルとそのカラムを削除します。もし、テーブルのキーあるいはそのテーブルのカラムにインデックスが張ってある場合はそれらも削除します。

シャードの一部を指定すると、そのシャードのテーブルは削除しません。テーブル内のレコードを削除するだけです。

例えば、テーブル内に以下のレコードがあるとします。

> - レコード1： `2016-03-18 00:30:00`

> - レコード2： `2016-03-18 01:00:00`

> - レコード3： `2016-03-18 02:00:00`

範囲として `2016-03-18 00:00:00` から `2016-03-18 01:30:00` までを指定すると、「レコード1」と「レコード2」を削除します。「レコード3」は削除しません。テーブルも削除しません。

Added in version 6.0.1: `dependent` パラメーターを使うと、対象テーブルを参照しているテーブル・カラムと対象シャードに関連しているテーブルも一緒に削除できます。

Added in version 6.0.9: `force` パラメーターを使うと壊れているテーブル・カラムでもできるだけ削除することができます。

## 7.3.38.2. 構文

このコマンドにはたくさんの引数があります。

必須引数は2つあります。 `logical_table` と `shard_key` です。

    logical_table_remove logical_table
                         shard_key
                         [min=null]
                         [min_border="include"]
                         [max=null]
                         [max_border="include"]
                         [dependent=no]
                         [force=no]

## 7.3.38.3. 使い方

削除したい論理テーブル名とシャードキーを指定します。

このセクションでは次のことについて説明します。

> - 基本的な使い方

> - 論理テーブルの一部を削除

> - 削除できないケース

> - 関連するテーブルと一緒に削除

> - 可能な限り壊れているテーブルを削除

> - 利用リソースの削減

### 7.3.38.3.1. 基本的な使い方

このコマンドを使うには事前に `sharding` プラグインを登録します。

実行例:

    plugin_register sharding
    # [[0,1337566253.89858,0.000355720520019531],true]

`logical_table` と `shard_key` だけを指定することで対象論理テーブル用のすべてのテーブルを削除できます。

以下は2つのシャードを作成するコマンドです。

実行例:

    table_create  Logs_20160318 TABLE_NO_KEY
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Logs_20160318 timestamp COLUMN_SCALAR Time
    # [[0,1337566253.89858,0.000355720520019531],true]
    table_create  Logs_20160319 TABLE_NO_KEY
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Logs_20160319 timestamp COLUMN_SCALAR Time
    # [[0,1337566253.89858,0.000355720520019531],true]

存在するシャードは logical_shard_list で確認できます。

実行例:

    logical_shard_list --logical_table Logs
    # [
    #   [
    #     0,
    #     1337566253.89858,
    #     0.000355720520019531
    #   ],
    #   [
    #     {
    #       "name": "Logs_20160318"
    #     },
    #     {
    #       "name": "Logs_20160319"
    #     }
    #   ]
    # ]

すべてのシャードを削除できます。

実行例:

    logical_table_remove \
      --logical_table Logs \
      --shard_key timestamp
    # [[0,1337566253.89858,0.000355720520019531],true]

すべてのシャードを削除した後はシャードは存在しません。

実行例:

    logical_shard_list --logical_table Logs
    # [[0,1337566253.89858,0.000355720520019531],[]]

### 7.3.38.3.2. 論理テーブルの一部を削除

次のパラメーターでシャードの範囲を指定できます。

> - `min`

> - `min_border`

> - `max`

> - `max_border`

各パラメーターについては logical_select の以下のドキュメントを参照してください。

> - min

> - min_border

> - max

> - max_border

指定した範囲がシャード内のすべてのレコードを含んでいなかったら、そのシャードのテーブルは削除しません。テーブル内の対象レコードのみ削除します。

指定した範囲がシャード内のすべてのレコードを含んでいれば、そのシャード用のテーブルを削除します。

以下はこの挙動を示すための論理テーブルです。この論理テーブルには2つのシャードがあります。

実行例:

    table_create  Logs_20160318 TABLE_NO_KEY
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Logs_20160318 timestamp COLUMN_SCALAR Time
    # [[0,1337566253.89858,0.000355720520019531],true]
    load --table Logs_20160318
    [
    {"timestamp": "2016-03-18 00:30:00"},
    {"timestamp": "2016-03-18 01:00:00"},
    {"timestamp": "2016-03-18 02:00:00"}
    ]
    # [[0,1337566253.89858,0.000355720520019531],3]
    table_create  Logs_20160319 TABLE_NO_KEY
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Logs_20160319 timestamp COLUMN_SCALAR Time
    # [[0,1337566253.89858,0.000355720520019531],true]
    load --table Logs_20160319
    [
    {"timestamp": "2016-03-19 00:30:00"},
    {"timestamp": "2016-03-19 01:00:00"}
    ]
    # [[0,1337566253.89858,0.000355720520019531],2]

`Logs_20160318` テーブルには次のレコードがあります。

> - レコード1： `"2016-03-18 00:30:00"`

> - レコード2： `"2016-03-18 01:00:00"`

> - レコード3： `"2016-03-18 02:00:00"`

`Logs_20160319` テーブルには次のレコードがあります。

> - レコード1： `"2016-03-19 00:30:00"`

> - レコード2： `"2016-03-19 01:00:00"`

次の範囲は `Logs_20160318` テーブル内の「レコード1」を含んでいませんが、 `Logs_20160319` テーブルのすべてのレコードを含んでいます。

パラメーター | 値
--- | ---
`min` | `"2016-03-18 01:00:00"`
`min_border` | `"include"`
`max` | `"2016-03-19 01:30:00"`
`max_border` | `"include"`

この範囲を指定した `logical_table_remove` は `Logs_20160318` テーブルの「レコード2」と「レコード3」を削除します。しかし、 `Logs_20160318` テーブルは削除しません。なぜなら、 `Logs_20160318` テーブルには「レコード1」があるからです。

この範囲を指定した `logical_table_remove` は `Logs_20160319` テーブルを削除します。なぜなら、この範囲は `Logs_20160319` テーブルのすべてのレコードを含んでいるからです。

この範囲を指定した `logical_table_remove` を使う例です。

実行例:

    logical_table_remove \
      --logical_table Logs \
      --shard_key timestamp \
      --min "2016-03-18 01:00:00" \
      --min_border "include" \
      --max "2016-03-19 01:30:00" \
      --max_border "include"
    # [[0,1337566253.89858,0.000355720520019531],true]

dump を使うと `Logs_20160318` テーブルに「レコード1」があることを確認できます。

実行例:

    dump
    # plugin_register sharding
    #
    # table_create Logs_20160318 TABLE_NO_KEY
    # column_create Logs_20160318 timestamp COLUMN_SCALAR Time
    #
    # load --table Logs_20160318
    # [
    # ["_id","timestamp"],
    # [1,1458228600.0]
    # ]

### 7.3.38.3.3. 削除できないケース

いくつか削除できない場合があります。詳細は 削除できないケース を参照してください。なぜなら `logical_table_remove` も同じようにチェックしているからです。

### 7.3.38.3.4. 関連するテーブルと一緒に削除

Added in version 6.0.1.

もし、自分がなにをしようとしているかちゃんと理解しているのであれば、 `--dependent yes` パラメーターを使うことで1回の `logical_table_remove` で対象シャードに依存しているテーブルとカラムも削除することができます。

以下が依存していると判断する条件です。もし、テーブル・カラムがこれらの条件のどれか1つでも満たしていてれば、そのテーブル・カラムは対象シャードに依存しています。

> - 対象シャードを参照しているテーブル・カラム

> - 対象シャード用のテーブル（= 名前の末尾が対象シャードと同じ `_YYYYMMDD` で、対象シャードが参照しているテーブル)

対象シャードを参照しているテーブル・カラムが1つ以上あれば、 `logical_table_remove` は失敗します。これは、参照先がなくなることを防ぐためです。

以下の `Bookmarks.log_20160320` カラムは対象シャードを参照しています。

実行例:

    table_create  Logs_20160320 TABLE_NO_KEY
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Logs_20160320 timestamp COLUMN_SCALAR Time
    # [[0,1337566253.89858,0.000355720520019531],true]
    table_create Bookmarks TABLE_HASH_KEY ShortText
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Bookmarks log_20160320 COLUMN_SCALAR Logs_20160320
    # [[0,1337566253.89858,0.000355720520019531],true]

デフォルトでは `logical_table_remove` で `Logs_20160320` を削除できません。

実行例:

    logical_table_remove \
      --logical_table Logs \
      --shard_key timestamp
    # [
    #   [
    #     -2,
    #     1337566253.89858,
    #     0.000355720520019531,
    #     "operation not permitted: <[table][remove] a column that references the table exists: <Bookmarks.log_20160320> -> <Logs_20160320",
    #     [
    #       [
    #         "remove",
    #         "lib/groonga/plugins/sharding/logical_table_remove.rb",
    #         199
    #       ]
    #     ]
    #   ]
    # ]

`--dependent yes` パラメーター付きの `logical_table_remove` では `Logs_20160320` を削除できます。 `Bookmarks.log_20160320` も一緒に削除します。

実行例:

    logical_table_remove \
      --logical_table Logs \
      --shard_key timestamp \
      --dependent yes
    # [[0,1337566253.89858,0.000355720520019531],true]

object_exist で `Logs_20160320` テーブルと `Bookmarks.log_20160320` カラムが削除されていることを確認できます。

実行例:

    object_exist Logs_20160320
    # [[0,1337566253.89858,0.000355720520019531],false]
    object_exist Bookmarks.log_20160320
    # [[0,1337566253.89858,0.000355720520019531],false]

対象シャード用のテーブルが1つ以上ある場合、 `--dependent yes` 付きの `logical_table_remove` はそれらも一緒に削除します。 対象シャード用のテーブルかどうかは対象シャードと同じ `_YYYYMMDD` がテーブル名の末尾にあるかどうかで判断します。

末尾が `_20160320` のテーブルは2つあります。 `NotRelated_20160320` テーブルは `Logs_20160320` テーブルから使われていません。 `Users_20160320` テーブルは `Logs_20160320` テーブルが使っています。 `Servers` テーブルもあり、これは `Logs_20160320` テーブルが使っています。

実行例:

    table_create  NotRelated_20160320 TABLE_PAT_KEY ShortText
    # [[0,1337566253.89858,0.000355720520019531],true]
    table_create  Users_20160320 TABLE_PAT_KEY ShortText
    # [[0,1337566253.89858,0.000355720520019531],true]
    table_create  Servers TABLE_PAT_KEY ShortText
    # [[0,1337566253.89858,0.000355720520019531],true]
    table_create  Logs_20160320 TABLE_NO_KEY
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Logs_20160320 timestamp COLUMN_SCALAR Time
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Logs_20160320 user COLUMN_SCALAR Users_20160320
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Logs_20160320 server COLUMN_SCALAR Servers
    # [[0,1337566253.89858,0.000355720520019531],true]

`--dependent yes` パラメーター付きの `logical_table_remove` は `Logs_20160320` テーブルと `Users_20160320` テーブルだけ削除します。なぜなら、 `Users_20160320` テーブルは名前の末尾が `_20160320` で、 `Logs_20160320` テーブルが使っているからです。 `NotRelated_20160320` テーブルと `Servers` テーブルは削除しません。なぜなら、 `NotRelated_20160320` は名前の末尾が `_20160320` ですが、 `Logs_20160320` テーブルは使っていないからです。 `Servers` テーブルは `Logs_20160320` テーブルが使っていますが、名前の末尾は `_20160320` ではありません。

実行例:

    logical_table_remove \
      --logical_table Logs \
      --shard_key timestamp \
      --dependent yes
    # [[0,1337566253.89858,0.000355720520019531],true]

`Logs_20160320` テーブルと `Users_20160320` テーブルは削除されていて、 `NotRelated_20160320` テーブルと `Servers` テーブルは削除されていないことを確認します。

実行例:

    object_exist Logs_20160320
    # [[0,1337566253.89858,0.000355720520019531],false]
    object_exist Users_20160320
    # [[0,1337566253.89858,0.000355720520019531],false]
    object_exist NotRelated_20160320
    # [[0,1337566253.89858,0.000355720520019531],true]
    object_exist Servers
    # [[0,1337566253.89858,0.000355720520019531],true]

### 7.3.38.3.5. 可能な限り壊れているテーブルを削除

Added in version 6.0.9.

対象のテーブルが壊れていた場合は削除できません。しかし、 `force` パラメーターを指定することで可能な限り削除することができます。

`--force yes` を指定すると、対象テーブルを可能な限り削除します。 `--force yes` と一緒に `--dependent yes` も指定することができます。

以下は `--force yes` の挙動を示すサンプルスキーマです。

実行例:

    table_create  Logs_20160320 TABLE_NO_KEY
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Logs_20160320 timestamp COLUMN_SCALAR Time
    # [[0,1337566253.89858,0.000355720520019531],true]
    table_create  Timestamps TABLE_PAT_KEY Time
    # [[0,1337566253.89858,0.000355720520019531],true]
    column_create Timestamps logs_20160320_timestamp \
      COLUMN_INDEX Logs_20160320 timestamp
    # [[0,1337566253.89858,0.000355720520019531],true]

`Timestamps.logs_20160320_timestamp` が壊れていると `Logs_20160320` を削除できません。

実行例:

    logical_table_remove \
      --logical_table Logs \
      --shard_key timestamp
    # [
    #   [
    #     -55,
    #     1337566253.89858,
    #     0.000355720520019531,
    #     "object corrupt: <[column][remove][index] hook has a dangling reference: <Logs_20160320.timestamp> -> <Timestamps.logs_20160320_",
    #     [
    #       [
    #         "remove",
    #         "lib/groonga/plugins/sharding/logical_table_remove.rb",
    #         199
    #       ]
    #     ]
    #   ]
    # ]

`--force yes` パラメーターを使うと、たとえ `Timestamps.logs_20160320_timestamp` が壊れていても `Logs_20160320` とこのテーブルのカラムを削除できます。

実行例:

    logical_table_remove \
      --logical_table Logs \
      --shard_key timestamp \
      --force yes
    # [[0,1337566253.89858,0.000355720520019531],true]

`Logs_20160320` とそのテーブルのカラムと `Timestamps.logs_20160320_timestamp` が削除されます。

実行例:

    object_exist Logs_20160320
    # [[0,1337566253.89858,0.000355720520019531],false]
    object_exist Logs_20160320.timestamp
    # [[0,1337566253.89858,0.000355720520019531],false]
    object_exist Timestamps.logs_20160320_timestamp
    # [[0,1337566253.89858,0.000355720520019531],false]

`--force yes` パラメーターは危険なパラメーターです。通常これを使う必要はありません。

### 7.3.38.3.6. 利用リソースの削減

このコマンドが使うリソースを削減できます。詳細は 利用リソースの削減 を参照してください。なぜなら `logical_table_remove` は table_remove と同じロジックを使っているからです。

## 7.3.38.4. 引数

このセクションでは `logical_table_remove` の引数について説明します。

### 7.3.38.4.1. 必須引数

いくつか必須の引数があります。

#### 7.3.38.4.1.1. `logical_table`

論理テーブル名を指定します。これは `_YYYYMMDD` をテーブル名から除いたものです。実際のテーブルが `Logs_20150203` や `Logs_20150203` といったものなら、論理テーブル名は `Logs` です。

logical_table も参照してください。

#### 7.3.38.4.1.2. `shard_key`

シャードキーとして使うカラム名を指定します。

shard_key も参照してください。

### 7.3.38.4.2. 省略可能引数

いくつか省略可能な引数があります。

#### 7.3.38.4.2.1. `min`

`shard_key` カラムの最小値を指定します。

min も参照してください。

#### 7.3.38.4.2.2. `min_border`

最小値を含めるかどうかを指定します。 `include` か `exclude` を指定します。デフォルトは `include` です。

min_border も参照してください。

#### 7.3.38.4.2.3. `max`

`shard_key` カラムの最大値を指定します。

max も参照してください。

#### 7.3.38.4.2.4. `max_border`

最大値を含めるかどうかを指定します。 `include` か `exclude` を指定します。デフォルトは `include` です。

max_border も参照してください。

#### 7.3.38.4.2.5. `dependent`

Added in version 6.0.1.

対象シャードに依存しているテーブル・カラムも一緒に削除するかどうかを指定します。

以下が依存していると判断する条件です。もし、テーブル・カラムがこれらの条件のどれか1つでも満たしていてれば、そのテーブル・カラムは対象シャードに依存しています。

> - 対象シャードを参照しているテーブル・カラム

> - 対象シャード用のテーブル（= 名前の末尾が対象シャードと同じ `_YYYYMMDD` で、対象シャードが参照しているテーブル)

`yes` を指定した場合は、対象シャードに依存しているテーブル・カラムも削除します。 `yes` を指定しなければ削除しません。もし、対象シャードを参照しているテーブル・カラムが1つ以上あればエラーになります。もし、対象シャード用のテーブルがあっても、それらを削除しません。

このパラメーターは注意して使ってください。危険なパラメーターです。

このパラメーターの使い方は 関連するテーブルと一緒に削除 を参照してください。

#### 7.3.38.4.2.6. `force`

Added in version 6.0.9.

もし問題があったとしても対象テーブル・カラムを削除したいかどうかを指定します。

このパラメーターは注意して使ってください。危険なパラメーターです。

このパラメーターの使い方は 可能な限り壊れているテーブルを削除 を参照してください。

## 7.3.38.5. 戻り値

このコマンドが成功したときは以下のようにボディは `true` になります:

    [HEADER, true]

このコマンドが失敗すると、 `HEADER` にエラーの詳細が含まれます。

`HEADER` については 出力形式 を参照してください。