Groonga 14.0.5 has been released

BloGroonga

2024-07-04

Groonga 14.0.5 has been released

Groonga 14.0.5 has been released!

How to install: Install

Changes

Here are important changes in this release:

Improvements

Added a new feature that objects(table or column) as remove as possible.

The crash safe feature of PGroonga will use this feature mainly.

PGroonga will apply PGroonga’s WAL to standby database automatically by using Custom WAL Resource Managers. However, when PGroonga use Custom WAL Resource Managers, all replications are stop if PGroonga fail application of PGroonga’s WAL due to break Groonga’s object. So, if broken objects exist in database, Groonga will try as remove as possible objects by using this feature.

Fixes

[query()] Fixed a bug that the order of evaluation of 'A || query("...", "B C")' is wrong

Here is occurrence condition of this problem.

We use OR search and query().
We use AND search in query().
The order of condition expression is 'A || query("...", "B C")'.

So, this problem doesn't occur if we use only query() or we don't use AND search in query().

We expect that {"name": "Alice", "memo": "Groonga user"} is hit in the following example. However, if this problem occurred, the following query had not been hit.

table_create Users TABLE_NO_KEY
column_create Users name COLUMN_SCALAR ShortText
column_create Users memo COLUMN_SCALAR ShortText

load --table Users
[
{"name": "Alice", "memo": "Groonga user"},
{"name": "Bob",   "memo": "Rroonga user"}
]
select Users \
  --output_columns 'name, memo, _score' \
  --filter 'memo @ "Groonga" || query("name", "Bob Rroonga")'
[[0,0.0,0.0],[[[0],[["name","ShortText"],["memo","ShortText"],["_score","Int32"]]]]]

After the fix, {"name": "Alice", "memo": "Groonga user"} is hit such as the following example.

select Users \
  --output_columns 'name, memo, _score' \
  --filter 'memo @ "Groonga" || query("name", "Bob Rroonga")'
[
  [
    0,
    1719376617.537505,
    0.002481460571289062
  ],
  [
    [
      [
        1
      ],
      [
        [
          "name",
          "ShortText"
        ],
        [
          "memo",
          "ShortText"
        ],
        [
          "_score",
          "Int32"
        ]
      ],
      [
        "Alice",
        "Groonga user",
        1
      ]
    ]
  ]
]

[select] Fixed a bug that a condition that evaluate prefix search in advance such as --query "A* OR B" returned wrong search result

This problem may occur when prefix search evaluate in advance. This problem doesn't occur a condition that evaluate prefix search in the end such as --query A OR B*.

If this problem occur, the Bo and the li of --query "Bo* OR li" are evaluated as a prefix search. As a result, The following query does not hit. Because li is evaluated as a prefix search as mentioned above.
```
table_create Users TABLE_NO_KEY
column_create Users name COLUMN_SCALAR ShortText

load --table Users
[
["name"],
["Alice"]
]

select Users \
  --match_columns name \
  --query "Bo* OR li"
[
  [
    0,
    1719377505.628048,
    0.0007376670837402344
  ],
  [
    [
      [
        0
      ],
      [
        [
          "_id",
          "UInt32"
        ],
        [
          "name",
          "ShortText"
        ]
      ]
    ]
  ]
]
```

Conclusion

Please refert to the following news for more details. News Release 14.0.5

Let's search by Groonga!

BloGroonga