BloGroonga

Groonga 12.0.5 has been released

Groonga 12.0.5 has been released!

How to install: Install

Changes

Here are important changes in this release:

Improvements

• select Improved a little bit of performance for prefix search by search escalation.

• select Added support for specifying a reference vector column with weight in drilldowns[LABEL]._key.

  If we specified a reference vector column with weight in drilldown's key, Groonga had returned incorrect results until now.

  For example, the following tag search had returned incorrect results until now.

    table_create Tags TABLE_PAT_KEY ShortText
  
    table_create Memos TABLE_HASH_KEY ShortText
    column_create Memos tags COLUMN_VECTOR|WITH_WEIGHT Tags
    column_create Memos date COLUMN_SCALAR Time
  
    load --table Memos
    [
    {"_key": "Groonga is fast!", "tags": {"full-text-search": 100}, "date": "2014-11-16 00:00:00"},
    {"_key": "Mroonga is fast!", "tags": {"mysql": 100, "full-text-search": 80}, "date": "2014-11-16 00:00:00"},
    {"_key": "Groonga sticker!", "tags": {"full-text-search": 100, "sticker": 10}, "date": "2014-11-16 00:00:00"},
    {"_key": "Rroonga is fast!", "tags": {"full-text-search": 100, "ruby": 20}, "date": "2014-11-17 00:00:00"},
    {"_key": "Groonga is good!", "tags": {"full-text-search": 100}, "date": "2014-11-17 00:00:00"}
    ]
  
    select Memos \
      --drilldowns[tags].keys tags \
      --drilldowns[tags].output_columns _key,_nsubrecs
    [
      [
        0,
        1656480220.591901,
        0.0005342960357666016
      ],
      [
        [
          [
            5
          ],
          [
            [
              "_id",
              "UInt32"
            ],
            [
              "_key",
              "ShortText"
            ],
            [
              "date",
              "Time"
            ],
            [
              "tags",
              "Tags"
            ]
          ],
          [
            1,
            "Groonga is fast!",
            1416063600.0,
            {"full-text-search":100}
          ],
          [
            2,
            "Mroonga is fast!",
            1416063600.0,
            {"mysql":100,"full-text-search":80}
          ],
          [
            3,
            "Groonga sticker!",
            1416063600.0,
            {"full-text-search":100,"sticker":10}
          ],
          [
            4,
            "Rroonga is fast!",
            1416150000.0,
            {"full-text-search":100,"ruby":20}
          ],
          [
            5,
            "Groonga is good!",
            1416150000.0,
            {"full-text-search":100}
          ]
        ],
        {
          "tags": [
            [
              8
            ],
            [
              [
                "_key",
                "ShortText"
              ],
              [
                "_nsubrecs",
                "Int32"
              ]
            ],
            [
              "full-text-search",
              5
            ],
            [
              "f",
              5
            ],
            [
              "mysql",
              1
            ],
            [
              "f",
              1
            ],
            [
              "sticker",
              1
            ],
            [
              "f",
              1
            ],
            [
              "ruby",
              1
            ],
            [
              "f",
              1
            ]
          ]
        }
      ]
     ]
  

  The above query returns correct results as below since this release.

    select Memos   --drilldowns[tags].keys tags   --drilldowns[tags].output_columns _key,_nsubrecs
    [
      [
        0,
        0.0,
        0.0
      ],
      [
        [
          [
            5
          ],
          [
            [
              "_id",
              "UInt32"
            ],
            [
              "_key",
              "ShortText"
            ],
            [
              "date",
              "Time"
            ],
            [
              "tags",
              "Tags"
            ]
          ],
          [
            1,
            "Groonga is fast!",
            1416063600.0,
            {
              "full-text-search": 100
            }
          ],
          [
            2,
            "Mroonga is fast!",
            1416063600.0,
            {
              "mysql": 100,
              "full-text-search": 80
            }
          ],
          [
            3,
            "Groonga sticker!",
            1416063600.0,
            {
              "full-text-search": 100,
              "sticker": 10
            }
          ],
          [
            4,
            "Rroonga is fast!",
            1416150000.0,
            {
              "full-text-search": 100,
              "ruby": 20
            }
          ],
          [
            5,
            "Groonga is good!",
            1416150000.0,
            {
              "full-text-search": 100
            }
          ]
        ],
        {
          "tags": [
            [
              4
            ],
            [
              [
                "_key",
                "ShortText"
              ],
              [
                "_nsubrecs",
                "Int32"
              ]
            ],
            [
              "full-text-search",
              5
            ],
            [
              "mysql",
              1
            ],
            [
              "sticker",
              1
            ],
            [
              "ruby",
              1
            ]
          ]
        }
      ]
    ]
  

• select Added support for doing drilldown with a reference vector with weight even if we use query or filter, or post_filter.

  If we specified a reference vector column with weight in drilldown's key when we use query or filter, or post_filter, Groonga had returned incorrect results or errors until now.

  For example, the following query had been erred until now.

    table_create Tags TABLE_PAT_KEY ShortText
  
    table_create Memos TABLE_HASH_KEY ShortText
    column_create Memos tags COLUMN_VECTOR|WITH_WEIGHT Tags
    column_create Memos date COLUMN_SCALAR Time
  
    load --table Memos
    [
    {"_key": "Groonga is fast!", "tags": {"full-text-search": 100}, "date": "2014-11-16 00:00:00"},
    {"_key": "Mroonga is fast!", "tags": {"mysql": 100, "full-text-search": 80}, "date": "2014-11-16 00:00:00"},
    {"_key": "Groonga sticker!", "tags": {"full-text-search": 100, "sticker": 10}, "date": "2014-11-16 00:00:00"},
    {"_key": "Rroonga is fast!", "tags": {"full-text-search": 100, "ruby": 20}, "date": "2014-11-17 00:00:00"},
    {"_key": "Groonga is good!", "tags": {"full-text-search": 100}, "date": "2014-11-17 00:00:00"}
    ]
  
    select Memos \
      --filter true \
      --post_filter true \
      --drilldowns[tags].keys tags \
      --drilldowns[tags].output_columns _key,_nsubrecs
    [
      [
        -22,
        1656473820.734894,
        0.03771400451660156,
        "[hash][add][           ] key size unmatch",
        [
          [
            "grn_hash_add",
            "hash.c",
            3405
          ]
        ]
      ],
      [
        [
        ]
      ]
    ]
  

  The above query returns correct results as below since this release.

    select Memos \
      --filter true \
      --post_filter true \
      --drilldowns[tags].keys tags \
      --drilldowns[tags].output_columns _key,_nsubrecs
    [
      [
        0,
        0.0,
        0.0
      ],
      [
        [
          [
            5
          ],
          [
            [
              "_id",
              "UInt32"
            ],
            [
              "_key",
              "ShortText"
            ],
            [
              "date",
              "Time"
            ],
            [
              "tags",
              "Tags"
            ]
          ],
          [
            1,
            "Groonga is fast!",
            1416063600.0,
            {
              "full-text-search": 100
            }
          ],
          [
            2,
            "Mroonga is fast!",
            1416063600.0,
            {
              "mysql": 100,
              "full-text-search": 80
            }
          ],
          [
            3,
            "Groonga sticker!",
            1416063600.0,
            {
              "full-text-search": 100,
              "sticker": 10
            }
          ],
          [
            4,
            "Rroonga is fast!",
            1416150000.0,
            {
              "full-text-search": 100,
              "ruby": 20
            }
          ],
          [
            5,
            "Groonga is good!",
            1416150000.0,
            {
              "full-text-search": 100
            }
          ]
        ],
        {
          "tags": [
            [
              4
            ],
            [
              [
                "_key",
                "ShortText"
              ],
              [
                "_nsubrecs",
                "Int32"
              ]
            ],
            [
              "full-text-search",
              5
            ],
            [
              "mysql",
              1
            ],
            [
              "sticker",
              1
            ],
            [
              "ruby",
              1
            ]
          ]
        }
      ]
    ]
  

Known Issues

• Currently, Groonga has a bug that there is possible that data is corrupt when we execute many additions, delete, and update data to vector column.

• *< and *> only valid when we use query() the right side of filter condition. If we specify as below, *< and *> work as &&.

  • 'content @ "Groonga" *< content @ "Mroonga"'

• Groonga may not return records that should match caused by GRN_II_CURSOR_SET_MIN_ENABLE.

Conclusion

Please refert to the following news for more details.

News Release 12.0.5

Let's search by Groonga!

Groonga 12.0.4 has been released

Groonga 12.0.4 has been released!

How to install: Install

Changes

Here are important changes in this release:

Improvements

• Ubuntu Added support for Ubuntu 22.04 (Jammy Jellyfish).

• We don't provide groonga-benchmark.

  Because nobody will not use it and we can't maintain it.

• status Added a new item memory_map_size.

  We can get the total memory map size in bytes of Groonga with status command.

  status
  [
    [
      0,
      1654237168.304533,
      0.0001480579376220703
    ],
    {
      (omitted)
      "memory_map_size": 70098944
    }
  ]
  

  For example, in Windows, if Groonga uses up physical memory and swap area, Groonga can't more mapping memory than that. Therefore, we can control properly memory map size by monitoring this value even if the environment does have not enough memory.

Fixes

• Fixed a bug Groonga's response may be slow when we execute request_cancel while executing a search.

  Especially, when the number of records of the search target is many, Groonga's response may be very slow.

• Fixed a bug that string list can't be casted to int32 vector.

  For example, the following cast had failed.

  • ["10", "100"] -> [10, 100]

  This bug only occurs when we specify apache-arrow into input_type as the argument of load. This bug occurs in Groonga 12.0.2 or later.

• Fixed a bug that Groonga Munin Plugins do not work on AlmaLinux 8 and CentOS 7.

Known Issues

• Currently, Groonga has a bug that there is possible that data is corrupt when we execute many additions, delete, and update data to vector column.

• *< and *> only valid when we use query() the right side of filter condition. If we specify as below, *< and *> work as &&.

  • 'content @ "Groonga" *< content @ "Mroonga"'

• Groonga may not return records that should match caused by GRN_II_CURSOR_SET_MIN_ENABLE.

Conclusion

Please refert to the following news for more details.

News Release 12.0.4

Let's search by Groonga!

Groonga 12.0.3 has been released

Groonga 12.0.3 has been released!

How to install: Install

Changes

Here are important changes in this release:

Improvements

• logical_count Improved memory usage while logical_count executed.

  Up to now, Groonga had been keeping objects(objects are tables and columns and indexes, and so on) and temporary tables that were allocated while logical_count executed until the execution of logical_count finished.

  Groonga reduces reference immediately after processing a shard by this feature. Therefore, Groonga can release memory while logical_count executed. The usage of memory of Groonga may reduce because of these reasons.

  This improvement is only valid for the reference count mode. We can valid the reference count mode by setting GRN_ENABLE_REFERENCE_COUNT=yes.

  In addition, Groonga releases temporary tables dynamically while logical_count is executed by this feature. Therefore, the usage of memory of Groonga reduces. This improvement is valid even if we don't set the reference count mode.

• dump Added support for MISSING_IGNORE/MISSING_NIL.

  If columns had MISSING_IGNORE/MISSING_NIL, the dump of these columns had failed until now. dump command supports these columns since this release.

• snippet,snippet_html Added support for text vector as input.

  For example, we can extract snippets of target text around search keywords against vector in JSON data as below.

     table_create Entries TABLE_NO_KEY
     column_create Entries title COLUMN_SCALAR ShortText
     column_create Entries contents COLUMN_VECTOR ShortText
  
     table_create Tokens TABLE_PAT_KEY ShortText   --default_tokenizer TokenNgram   --normalizer NormalizerNFKC130
     column_create Tokens entries_title COLUMN_INDEX|WITH_POSITION Entries title
     column_create Tokens entries_contents COLUMN_INDEX|WITH_SECTION|WITH_POSITION   Entries contents
  
     load --table Entries
     [
     {
       "title": "Groonga and MySQL",
       "contents": [
         "Groonga is a full text search engine",
         "MySQL is a RDBMS",
         "Mroonga is a MySQL storage engine based on Groonga"
       ]
     }
     ]
  
     select Entries\
       --output_columns 'snippet_html(contents), contents'\
       --match_columns 'title'\
       --query Groonga
     [
       [
         0,
         0.0,
         0.0
       ],
       [
         [
           [
             1
           ],
           [
             [
               "snippet_html",
               null
             ],
             [
               "contents",
               "ShortText"
             ]
           ],
           [
             [
               "<span class=\"keyword\">Groonga</span> is a full text search engine",
               "Mroonga is a MySQL storage engine based on <span class=\"keyword\">Groonga</span>"
             ],
             [
               "Groonga is a full text search engine",
               "MySQL is a RDBMS",
               "Mroonga is a MySQL storage engine based on Groonga"
             ]
           ]
         ]
       ]
     ]
  

  Until now, if we specified snippet* like --output_columns 'snippet_html(contents[1]), we could extract snippets of target text around search keywords against the vector as below. However, we didn't know which we should output elements. Because we didn't know which element was hit on search.

     select Entries\
       --output_columns 'snippet_html(contents[0]), contents'\
       --match_columns 'title'\
       --query Groonga
     [
       [
         0,
         0.0,
         0.0
       ],
       [
         [
           [
             1
           ],
           [
             [
               "snippet_html",
               null
             ],
             [
               "contents",
               "ShortText"
             ]
           ],
           [
             [
               "<span class=\"keyword\">Groonga</span> is a full text search engine"
             ],
             [
               "Groonga is a full text search engine",
               "MySQL is a RDBMS",
               "Mroonga is a MySQL storage engine based on Groonga"
             ]
           ]
         ]
       ]
     ]
  

• [vector_join] Added a new function vector_join().

  This function can concatenate each elements. We can specify delimiter in the second argument in this function.

  For example, we could execute snippet() and snippet_html() against vector that concatenate each elements as below.

     plugin_register functions/vector
  
     table_create Entries TABLE_NO_KEY
     column_create Entries title COLUMN_SCALAR ShortText
     column_create Entries contents COLUMN_VECTOR ShortText
  
     table_create Tokens TABLE_PAT_KEY ShortText   --default_tokenizer TokenNgram   --normalizer NormalizerNFKC130
     column_create Tokens entries_title COLUMN_INDEX|WITH_POSITION Entries title
     column_create Tokens entries_contents COLUMN_INDEX|WITH_SECTION|WITH_POSITION   Entries contents
  
     load --table Entries
     [
     {
       "title": "Groonga and MySQL",
       "contents": [
         "Groonga is a full text search engine",
         "MySQL is a RDBMS",
         "Mroonga is a MySQL storage engine based on Groonga"
       ]
     }
     ]
  
     select Entries\
       --output_columns 'snippet_html(vector_join(contents, "\n")), contents'\
       --match_columns 'title'\
       --query Groonga --output_pretty yes
     [
       [
         0,
         1650849001.524027,
         0.0003361701965332031
       ],
       [
         [
           [
             1
           ],
           [
             [
               "snippet_html",
               null
             ],
             [
               "contents",
               "ShortText"
             ]
           ],
           [
             [
               "<span class=\"keyword\">Groonga</span> is a full text search engine\nMySQL is a RDBMS\nMroonga is a MySQL storage engine based on <span class=\"keyword\">Groonga</span>"
             ],
             [
               "Groonga is a full text search engine","MySQL is a RDBMS","Mroonga is a MySQL storage engine based on Groonga"
             ]
           ]
         ]
       ]
     ]
  

• Indexing Ignore too large a token like online index construction.

  Groonga doesn't occur error, but Groonga ignores too large a token when we execute static index construction. However, Groonga output warning in this case.

Fixes

• Fixed a bug that we may be not able to add a key to a table of patricia trie.

  This bug occurs in the following conditon.

  • If a table of patricia trie already has a key.
  • If the additional key is 4096 bytes.

Known Issues

• Currently, Groonga has a bug that there is possible that data is corrupt when we execute many additions, delete, and update data to vector column.

• *< and *> only valid when we use query() the right side of filter condition. If we specify as below, *< and *> work as &&.

  • 'content @ "Groonga" *< content @ "Mroonga"'

• Groonga may not return records that should match caused by GRN_II_CURSOR_SET_MIN_ENABLE.

Conclusion

Please refert to the following news for more details.

News Release 12.0.3

Let's search by Groonga!

Groonga 12.0.2 has been released

Groonga 12.0.2 has been released!

How to install: Install

Changes

Here are important changes in this release:

Improvements

• logical_range_filter Added support for reducing reference immediately after processing a shard.

  Groonga had reduced reference all shards when the finish of logical_range_filter until now. Groonga reduces reference immediately after processing a shard by this feature. The usage of memory may reduce while logical_range_filter executes by this feature.

  This feature is only valid for the reference count mode. We can valid the reference count mode by setting GRN_ENABLE_REFERENCE_COUNT=yes.

  Normally, Groonga keep objects(tables and column and index, and so on) that Groonga opened even once on memory. However, if we open many objects, Groonga uses much memory. In the reference count mode release objects that are not referenced anywhere from memory. The usage of memory of Groonga may reduce by this.

• We increased the stability of the feature of recovering on crashes.

  This feature is experimental and it is disabled by default. Therefore, the following improvements are no influence on ordinary users.

  • We fixed a bug that the index was broken when Groonga crashed.
  • We fixed a bug that might remain a lock.
  • We fixed a bug that Groonga crashed while it was recovering the crash.

• Improved performance for mmap if anonymous mmap available.[GitHub:MariaDB/server#1999][Suggested by David CARLIER]

  The performance of Groonga is improved a bit by this improvement.

• Indexing Added support for the static index construction against the following types of columns.

  • The non-reference vector column with weight
  • The reference vector column with weight
  • The reference scalar column

  These columns have not supported the static index construction until now. Therefore, the time of making the index has longed even if we set the index against these columns after we loaded data into them. By this improvement, the time of making the index is short in this case.

• column_create Added new flags MISSING_* and INVALID_*.

  We added the following new flags for column_create.

  • MISSING_ADD
  • MISSING_IGNORE

  • MISSING_NIL

  • INVALID_ERROR
  • INVALID_WARN
  • INVALID_IGNORE

  Normally, if the data column is a reference data column and the nonexistent key is specified, a new record for the nonexistent key is newly created automatically.

  The behavior that Groonga adds the key automatically into the column of reference destination is useful in the search like tag search. Because Groonga adds data automatically when we load data.

  However, this behavior is inconvenient if we need the other data except for the key. Because a record that only has the key exists.

  We can change this behavior by using flags that are added in this release.

  • MISSING_ADD: This is the default value. This is the same behavior as the current.

    If the data column is a reference data column and the nonexistent key is specified, a new record for the nonexistent key is newly created automatically.

  • MISSING_IGNORE:

    If the data column is a reference data column and the nonexistent key is specified, the nonexistent key is ignored. If the reference data column is a scalar column, the value is GRN_ID_NIL. If the reference data column is a vector column, the element is just ignored as below ::

    ["existent1", "nonexistent", "existent2"] -> ["existent1" "existent2"]

  • MISSING_NIL:

    If the data column is a reference data column and the nonexistent key is specified, the nonexistent key in a scalar column and a vector column is treated as GRN_ID_NIL ::

    ["existent1", "nonexistent", "existent2"] -> ["existent1", "" (GRN_ID_NIL), "existent2"]

  • INVALID_ERROR: This is the default value. This is the same behavior as the current except an error response of a vector column case.

    If we set the invalid value (e.g.: XXX for UInt8 scalar column), the set operation is treated as an error. If the data column is a scalar column, load reports an error in log and response. If the data column is a vector column, load reports an error in log but doesn't report an error in response. This is an incompatible change.

  • INVALID_WARN:

    If we set the invalid value (e.g.: XXX for UInt8 scalar column), a warning message is logged and the set operation is ignored. If the target data column is a reference vector data column, MISSING_IGNORE and MISSING_NIL are used to determine the behavior.

  • INVALID_IGNORE:

    If we set the invalid value (e.g.: XXX for UInt8 scalar column), the set operation is ignored. If the target data column is a reference vector data column, MISSING_IGNORE and MISSING_NIL are used to determine the behavior.

• dump column_list Added support for MISSING_* and INVALID_* flags.

  These commands doesn't show MISSING_ADD and INVALID_ERROR flags to keep backward compatibility. Because these flags show the default behavior.

• schema Added support for MISSING_* and INVALID_* flags.

  MISSING_AND and INVALID_ERROR flags aren't shown in flags to keep backward compatibility. However, new missing and invalid keys are added to each column.

• We provided the package of Amazon Linux 2.

• [Windows] Dropped support for building with Visual Studio 2017.

  Because we could not use windows-2016 image on GitHub Actions.

Known Issues

• Currently, Groonga has a bug that there is possible that data is corrupt when we execute many additions, delete, and update data to vector column.

• *< and *> only valid when we use query() the right side of filter condition. If we specify as below, *< and *> work as &&.

  • 'content @ "Groonga" *< content @ "Mroonga"'

• Groonga may not return records that should match caused by GRN_II_CURSOR_SET_MIN_ENABLE.

Conclusion

Please refert to the following news for more details.

News Release 12.0.2

Let's search by Groonga!

Groonga 12.0.1 has been released

Groonga 12.0.1 has been released!

How to install: Install

Changes

Here are important changes in this release:

Improvements

• query_expand Added a support for synonym group.

  Until now, We had to each defined a keyword and synonyms of the keyword as below when we use the synonym search.

  table_create Thesaurus TABLE_PAT_KEY ShortText --normalizer NormalizerAuto
  # [[0, 1337566253.89858, 0.000355720520019531], true]
  column_create Thesaurus synonym COLUMN_VECTOR ShortText
  # [[0, 1337566253.89858, 0.000355720520019531], true]
  load --table Thesaurus
  [
  {"_key": "mroonga", "synonym": ["mroonga", "tritonn", "groonga mysql"]},
  {"_key": "groonga", "synonym": ["groonga", "senna"]}
  ]
  

  In the above case, if we search mroonga, Groonga search mroonga OR tritonn OR "groonga mysql" as we intended. However, if we search tritonn, Groonga search only tritonn. If we want to search tritonn OR mroonga OR "groonga mysql" even if we search tritonn, we need had added a definition as below.

  load --table Thesaurus
  [
  {"_key": "tritonn", "synonym": ["tritonn", "mroonga", "groonga mysql"]},
  ]
  

  In many cases, if we expand mroonga to mroonga OR tritonn OR "groonga mysql", we feel we want to expand tritonn and "groonga mysql" to mroonga OR tritonn OR "groonga mysql". However, until now, we had needed additional definitions in such a case. Therefore, if target keywords for synonyms are many, we are troublesome to define synonyms. Because we need to define many similar definitions.

  In addition, when we remove synonyms, we are troublesome because we need to execute remove against many records.

  We can make a group by deciding on a representative synonym record since this release. For example, the all following keywords are the "mroonga" group.

  load --table Synonyms
  [
    {"_key": "mroonga": "representative": "mroonga"}
  ]
  
  load --table Synonyms
  [
    {"_key": "tritonn": "representative": "mroonga"},
    {"_key": "groonga mysql": "representative": "mroonga"}
  ]
  

  In this case, mroonga is expanded to mroonga OR tritonn OR "groonga mysql". In addition, tritonn and "groonga mysql" are also expanded to mroonga OR tritonn OR "groonga mysql".

  When we want to remove synonyms, we execute just remove against a target record. For example, if we want to remove "groonga mysql" from synonyms, we just remove {"_key": "groonga mysql": "representative": "mroonga"}.

• query_expand Added a support for text vector and index.

  We can use text vector in a synonym group as below.

  table_create SynonymGroups TABLE_NO_KEY
  [[0,0.0,0.0],true]
  column_create SynonymGroups synonyms COLUMN_VECTOR ShortText
  [[0,0.0,0.0],true]
  table_create Synonyms TABLE_PAT_KEY ShortText
  [[0,0.0,0.0],true]
  column_create Synonyms group COLUMN_INDEX SynonymGroups synonyms
  [[0,0.0,0.0],true]
  load --table SynonymGroups
  [
  ["synonyms"],
  [["rroonga", "Ruby groonga"]],
  [["groonga", "rroonga", "mroonga"]]
  ]
  [[0,0.0,0.0],2]
  query_expand Synonyms.group "rroonga"
  [
    [
      0,
      0.0,
      0.0
    ],
    "((rroonga) OR (Ruby groonga) OR (groonga) OR (rroonga) OR (mroonga))"
  ]
  

• Added support for disabling a backtrace by the environment variable.

  We can disable output a backtrace by using GRN_BACK_TRACE_ENABLE. If we set GRN_BACK_TRACE_ENABLE=no, Groonga doesn't output a backtrace.

  Groonga output backtrace to a stack area. Therefore, Groonga may crash because Groonga uses up stack area depending on the OS. In such cases, we can avoid crashes by using GRN_BACK_TRACE_ENABLE=no.

• select Improved performance for --slices.

• [Windows] Added support for Visual Studio 2022.

• select Added support for specifing max intervals for each elements in near search.

  For example, we can specify max intervals for each phrase in a near phrase search. We make documentation for this feature in the future. Therefore, we will make more details later.

• groonga-server-http We could use groonga-server-http even if Groonga of RPM packages.

Fixes

• [Windows] Fixed a crash bug when Groonga output backtrace.

Known Issues

• Currently, Groonga has a bug that there is possible that data is corrupt when we execute many additions, delete, and update data to vector column.

• *< and *> only valid when we use query() the right side of filter condition. If we specify as below, *< and *> work as &&.

  • 'content @ "Groonga" *< content @ "Mroonga"'

• Groonga may not return records that should match caused by GRN_II_CURSOR_SET_MIN_ENABLE.

Conclusion

Please refert to the following news for more details.

News Release 12.0.1

Let's search by Groonga!