お知らせ - 15系#

15.1.4リリース - 2025-07-29#

今回のリリースでは、*ONPP演算子のフレーズ間の距離の計算の間違いを修正しました。

修正#

[順序付き近傍フレーズ直積検索] フレーズ間の距離の計算の間違いを修正しました#

この問題は、 *ONPP-1,0,10"(abc bcd) (defg)" のように *ONPP と MAX_ELEMENT_INTERVAL を指定して使っている時に発生することがあります。 MAX_ELEMENT_INTERVAL を使ってない場合は、この問題は発生しません。

*ONPP の構文や使い方については以下のリンクを参照してください。

この問題が発生すると、以下のようなことが起こる可能性があります。

  • ヒットしないはずのレコードを返すことがあります。

  • ヒットするはずのレコードを返さないことがあります。

15.1.3リリース - 2025-07-18#

改良#

[Apache Arrow] Apache Arrow C++ 21.0.0 をサポートしました#

15.1.2リリース - 2025-07-07#

改良#

[Windows] Visual Studio 2019 でビルドしたパッケージのサポートをやめました#

このリリースから以下のパッケージは提供しなくなります。

  • groonga-xx.x.x-x64-vs2019.zip

  • groonga-xx.x.x-x64-vs2019-with-vcruntime.zip

修正#

[近傍フレーズ検索] フレーズ間の距離の計算の間違いを修正しました#

この問題は、以下のように*NP や *NPP、 *ONP を MAX_ELEMENT_INTERVAL を指定して使っている時に発生することがあります。

  • *NP-1,0,12"abc ef"

  • *NPP-1,0,10"(abc bcd) (ef)"

  • *ONP-1,0,5|6 "abc defghi jklmnop"

MAX_ELEMENT_INTERVAL を使ってない場合は、この問題は発生しません。

*NP や *NPP、 *ONP の構文や使い方については以下のリンクを参照してください。

この問題が発生すると、以下のようなことが起こる可能性があります。

  • ヒットしないはずのレコードを返すことがあります。

  • ヒットするはずのレコードを返さないことがあります。

15.1.1リリース - 2025-06-02#

このリリースでは、TokenMecabがスペースを含むユーザー定義エントリを単一トークンとして保持できるようにする変更をおこないました。

改良#

TokenMecab: スペースを含むユーザー定義エントリの意図しないトークン分割を修正#

従来、TokenMecabはスペースを含むユーザー定義エントリ（例: "search engine"）を"search"や"engine"のように別々のトークンとして分割していました。本リリースではこの問題を修正し、スペースを含むエントリを"search engine"のように単一のトークンとしてトークナイズできるように修正しました。

tokenize TokenMecab "search engine" --output_pretty yes
[
  [
    0,
    1748413131.972704,
    0.0003032684326171875
  ],
  [
    {
      "value": "search engine",
      "position": 0,
      "force_prefix": false,
      "force_prefix_search": false
    }
  ]
]

修正#

ドキュメント内の複数の誤記を修正#

GH-2332、GH-2333、GH-2334、GH-2335、GH-2336、GH-2337、GH-2338

Vasilii Lakhinさんがパッチ提供。

感謝#

  • Vasilii Lakhinさん

15.0.9リリース - 2025-05-08#

このリリースでは、トークナイザのオプションを追加してトークンの確認を簡単にするとともに、符号なし整数を負の数で除算したときのセマンティクスを改善しました。

改良#

tokenize/table_tokenize: output_styleオプションの追加#

output_styleオプションをtokenize/table_tokenizeコマンドに追加しました。これにより、トークンの属性情報を表示する必要がない場合に、トークン情報のみを表示できます。

以下は output_styleオプション使用例です。

tokenize TokenNgram "Fulltext Search" --output_style simple
[
  [
    0,
    1746573056.540744,
    0.0007045269012451172
  ],
  [
    "Fu",
    "ul",
    "ll",
    "lt",
    "te",
    "ex",
    "xt",
    "t ",
    " S",
    "Se",
    "ea",
    "ar",
    "rc",
    "ch",
    "h"
  ]
]

X / 負の整数のセマンティクスを明確にした#

これまでは、符号なし整数Xを-1または-1.0で割った場合のみ-Xを返すようにしていました。今回のリリース以降は任意の負の整数で割った際にも数学的に期待される負の結果を返すようになります。

  • 変更前： X / -2は必ずしも-(X / 2)を返すとは限りませんでした。

  • 変更後： X / -2は常に-(X / 2)を返すようになります。

これは後方非互換な変更ですが、この挙動に依存しているユーザーはいないはずです。

15.0.4リリース - 2025-03-29#

改良#

X / -1とX / -1.0のセマンティクスを明確にした#

多くの言語ではX / -1とX / -1.0は-Xを返します。しかし、GroongaはXが非負整数のときは-Xを返さないことがありました。

このリリースからはX / -1とX / -1.0は常に-Xを返します。

これは後方非互換な変更ですが、この挙動に依存しているユーザーはいないはずです。

15.0.3リリース - 2025-03-10#

改良#

静的なインデックス構築方法: 語彙表がTABLE_HASH_KEYの場合でも並列構築をサポート#

並列静的インデックス構築は内部的にすべての単語をソートして処理しています。TABLE_PAT_KEYとTABLE_PAT_KEYは効率よくこの処理をできます。なぜなら、これらはツリーベースだからです。しかし、TABLE_HASH_KEYは効率よくこの処理をすることができません。なぜならツリーベースではないからです。そのため、語彙表がTABLE_HASH_KEYの場合は並列静的インデックス構築をサポートしていませんでした。

このリリースでは語彙表がTABLE_HASH_KEYの場合でも並列静的インデックス構築を使えるようにしました。これは通常の方法で単語をソートしています。そのため、それほど効率的ではありません。語彙表がTABLE_HASH_KEYの場合の並列静的インデックス構築は語彙表がTABLE_PAT_KEYまたはTABLE_DAT_KEYの場合より遅いでしょう。しかし、語彙表がTABLE_HASH_KEYで直列に静的インデックス構築をするよりも速い可能性があります。

15.0.2リリース - 2025-02-21#

修正#

静的なインデックス構築方法: 並列に構築するとオプションを無視することがある問題を修正#

静的なインデックス構築を並列で実行しているときにGroongaがノーマライザー、トークナイザー、トークンフィルターのオプションを無視することがある問題を修正しました。

次の場合に発生することがあります。

NormalizerTable を使っていてこの問題が発生した場合、静的なインデックス構築は失敗します。 NormalizerTable には必須の引数がありますが、オプションが無視されると必須の引数が指定されていないことになるためです。

15.0.1リリース - 2025-02-20#

改良#

[Ubuntu] Ubuntu 20.04 (Focal Fossa) のサポート終了#

Ubuntu 20.04は2025年5月にサポート終了（EOL）となるため、今回のリリースからサポートを終了しました。

15.0.0リリース - 2025-02-09#

毎年恒例の肉の日メジャーリリースです！このリリースには後方互換性が壊れる変更はありません！既存のデータベースを移行せずにGroongaをアップグレードできます。既存のデータベースをそのまま使い続けることができます。

改良#

TABLE_PAT_KEY: キーの型としてFloat32をサポート#

GH-2211

TABLE_PAT_KEYは高速な検索のために内部では数値キーをエンコード・デコードしています。そのため、TABLE_PAT_KEYはキーをどのようにエンコード・デコードするかを知らなければいけません。TABLE_PAT_KEYはこのリリースまではFloat32をどのようにエンコード・デコードすればよいかを知りませんでした。今回のリリースから、TABLE_PAT_KEYはFloat32をエンコード・デコードできるようになりました。そのため、Float32を他のInt32やFloatのような数値型のようにTABLE_PAT_KEYのキーとして使えるようになりました。

このページでは