書店ブラウズしてたら発見。新作は何年ぶりなんだろう。しかし、僕の年齢くらいの人間がソノラマ文庫のエリアをウロ付いてるのは、客観的に見てどうなのかね?(笑)
タイトルは渋谷の某居酒屋の店員カマチ君の名言。
ということで、こへださん主催の突発性飲み会に参加した。こへださん以外は初めての人ばかりだというのもアレだが、そもそもこへださんともあまり縁がないままの参加というなかなか無謀な試みを。
集まった人達は、流石こへだ人脈というか、一癖も二癖もあるようなステキな人達で、いろいろと面白い話を聞かせてもらった。仕事の辛い話もいっぱい聞いてしまったので「オレってまだまだ楽なんだなぁ」とか思ったり。さすがに月250時間の残業が3ヶ月続いたことはなかったし、有休が150日残ってるなんて状態でもないしなぁ。
まぁ、こういったツラさ自慢を含め、楽しい時間を過ごせた。世の中にはいろんな人がいるなぁ。
南の方からもお告げ。「登別温泉がオススメ」と。ちゅーか、どんだけ北海道をススメるねん。行きたくなるじゃないか!
ということで、ドラぷらで、練馬IC〜青森ICまでの所要時間とかを調べてみると、およそ8時間。距離は約720km。これにフェリーとかが入ると、、、と思って、そちらも調べてみたら「2007年12月31日〜2008年1月2日まで全便運休です」なんてあるじゃないか! やっぱり年末年始はキケンがいっぱい。
「うまいものは○○」とかオススメされても、店が休みの確率が高そうな気もするなぁ。
「大阪王将の餃子セットを買いすぎたので消費するパーティ」へ参加。そこへの差し入れで、かなりひさびさに「草月」の「黒松」を買いに東十条まで行ってきた。
お店に駐車場が無いのは知っていたので、近くのコインパーキングを事前に探して、そこをナビの目的地にセット。こういうときは駐車場の満車・空車情報が分かる「Yahoo!カーナビ」が本当に便利。ステマじゃなくて個人の見解な。
いままでは、車載のナビで駐車場を目的地にして、その混み具合は「s-park」で確認するということをしていたんだけど、s-park はブラウザベースなので、情報が自動更新されない。リロードしてやれば最新情報にはなるけど、やっぱりちょっと面倒臭い。そういった操作をすることなく、目的地近くの駐車場の満空情報が分かるのはありがたい(もちろん、その情報提供に対応している駐車場のみだけど)。
無事に空いているコインパーキングへ駐車して、草月に到着したら、店外に10人程度の列ができていた。
ほとんどの客はどら焼きの「黒松」目当てなので、基本的には「注文→箱詰め」なだけなので、サクサク進むのかと思いきや、なんか進みが遅い。なんだろなー?と思いながら、ようやく店内へ入ったら、なんかものすごい数の箱を受け取ろうとしている老夫婦がいた。ざっと見で100個以上のどら焼きを買っていたようだ。そういやお歳暮とかのシーズンだもんな。
あと、店内には「研修中」の腕章を付けた店員さんがたくさんいた。ちょっと客対応も不慣れな様子だったので、繁忙期のバイトさんかな。その辺もネックになって、なかなか進まなかった模様。オレの対応をしてくれた店員さんも、ひとつひとつ客対応のステップを思い出しながらトークしていたので、生暖かく見守る感じで応対した(笑)
それはそれとして、午後から餃子パーティに参加。
王将餃子を消費する会なのに、なぜか手作り餃子を更に増やした。合計120個くらいだったかな。オレの餃子の包み方だけ他の人と違っていた。割とメジャーな包み方かと思ってたんだけど、違ったのか。
他にもいろいろ料理やらデザートやらがたんまりの会で、超満腹になって帰ったのであった。
先日「Elasticsearch 5.x では Crowi の検索が動かないかも知れない」という日記を書いてから、もう少し調べていた。
下記の記事を参考にして、 mappings.json
内部の "type": "multi_field"
を "type" : "string"
に変えてやれば Elasticsearch 5.x でも検索インデックスの再構築が成功するようになる、、、のかと思いきや、うまくいかない。
何が悪いんだろう?と思いつつ、試しに Elasticsearch 用の Node.js 版クライアントである elasticsearch.js を v11 系から v12 系に上げてみたところ、検索インデックスの再構築に成功するようになった。
何が変わったんだろう?と思って、Changelog を見てみると、v12 からはデフォルトの ApiVersion が "5.0" になったようだ。バックエンドの Elasticsearch が 5.x なら ApiVersion も 5.0 じゃないとダメってことかな?
インデックスの再構築ができるようになって、検索を実行してみると、次はこんなエラーが出た。
{
"error": {
"root_cause": [
{
"type": "parsing_exception",
"reason": "The field [fields] is no longer supported, please use [stored_fields] to retrieve stored fields or _source filtering if the field is not stored",
"line": 1,
"col": 11
}
],
"type": "parsing_exception",
"reason": "The field [fields] is no longer supported, please use [stored_fields] to retrieve stored fields or _source filtering if the field is not stored",
"line": 1,
"col": 11
},
"status": 400
}
エラーメッセージに言われるがままに、Crowi 内部で生成しているクエリの fields
の部分を stored_fields
に変更してみると検索結果が返ってくるようになった。
var query = {
index: this.index_name,
type: 'pages',
body: {
//fields: fields, // **OLD**
stored_fields: fields, // **NEW**
sort: [ {_score: { order: 'desc'} }],
query: {}, // query
}
};
ここまでをまとめると、Crowi を Elasticsearch 5.x に対応させるには以下のことが必要そうだということまで分かった。
"type": "multi_field"
から "type" : "string"
へ変更fields
から store_fields
へ変更これで Elasticseach 5.x を「新規に使う場合」は大丈夫そうかな。
ただ、この変更が「既に 2.x を利用している環境」に与える影響も確認しないと危なそう。場合によっては、Elasticseach のバージョンを確認した上で挙動の変更とかもありえるかも?
もうちょい確認を続けよう。
▽ よきゅん [もしかして罰金です。罰として今週一杯は靴べらを買わないでください!]
▽ スズキシゲヲ [ウホッ、いいソノラマ文庫。くらっしゃーじょうって何年ぶり!]