Groonga 3.0.8 has been released

2013-09-29

Groonga 3.0.8 has been released

How to install: Install

There are three topics in this release.

Improved usability of administration interface
Supported groonga_query_log_path directive
Supported cascaded delete

Improved usability of administration interface

As you know, groonga provides administration web interface as a default. In this release, following usability related issues are fixed.

Error handling of select functionality. This change shows error message and hides loading dialog.
Submit search form with the enter key.
Show placeholder in search form.

All above issues are fixed by @orangain who submit patches for us. It's great work! Thanks orangain!

Supported groonga_query_log_path directive

In this release, you can customize query log path for groonga-httpd.

In the previous releases, you need to check access.log or error.log for investigating the query issue. If you process query via GET method, it is enough to investigate, but if you use POST method, that is not good enough on query error.

To customize query log path, use groonga_query_log_path on groonga-httpd.conf.

The default query log path is also changed.

Before:

/var/log/groonga/httpd/groonga.log

After:

/var/log/groonga/httpd/groonga-query.log

Use groonga_query_log_path directive in http, server or location block. Now you can specify this directive in each location block, you can save query log for each database.

location /d/ {
  groonga on;
  # You can disable query log for groonga.
  groonga_query_log_path /var/log/groonga/httpd/groonga-location-d.log;
}

location /d2/ {
  groonga on;
  # You can disable query log for groonga.
  groonga_query_log_path /var/log/groonga/httpd/groonga-location-d2.log;
}

See the following documentation about groonga_query_log_path directive.

Supported cascaded delete

In this release, groonga supports cascaded delete.

For example, assume that there are some URLs associated for a person. If you store user information and URL for separated table, you use following schema for instance.

table_create Users TABLE_HASH_KEY ShortText
table_create URLs TABLE_HASH_KEY ShortText

column_create Users bookmarks COLUMN_VECTOR URLs
column_create URLs author COLUMN_SCALAR Users

column_create URLs bookmarks_index COLUMN_INDEX Users bookmarks

Then load sample data:

load --table Users
[
{"_key": "mori", "bookmarks": ["http://mroonga.org/", "http://groonga.org/", "http://ranguba.org/"]}
]

load --table URLs
[
{"_key": "http://groonga.org/", "author": "mori"}
{"_key": "http://mroonga.org/", "author": "hayashi"}
]

In this case, Users table stores the key which refers URLs table in bookmarks column. That is the reason why simply you can't delete record of URLs.

Here is the query which fails to delete:

delete URLs --key "http://groonga.org/"

Here is the error message when you execute the above query:

[
  [
    -2,1380092940.21387,
    0.000238895416259766,
    "undeletable record (URLs:2) has value (bookmarks_index:1)",
    [
      ["is_deletable","db.c",1564]
    ]
  ],
  false
]

If you want to delete above records, you must delete the record which refers in advance, then delete data by above query. That is a very boring task that you need to delete each records step by step.

In this release, there is one thing you need to do:

delete URLs --key "http://groonga.org/"

"Delete" command detects the records which refers, then automatically delete them.

It remains "http://mroonga.org" and "http://ranguba.org" on bookmarks column, because they have nothing to do with the key - "http://groonga.org".

Conclusion

See Release 3.0.8 2013/08/29 about detailed changes since 3.0.6.

Let's search by groonga!

BloGroonga