dbのversionを返すAPI

[守岡知彦 / MORIOKA Tomohiko]

>>>>> In [chise-ja : No.00253] 
>>>>>	"師さん" = Shigeki Moro <s-moro ＠ hanazono.ac.jp> wrote:

師さん> 今日、Perl の CHISE 的正規表現拡張モジュールがあまりにとろいの
師さん> で、一回 db から引っ張ってきた結果をキャッシュしておく仕組みを
師さん> 作っていたりしたのですが、そこでふと思ったことがあります。

師さん> db が成長していくことを考えると、このようなキャッシュは折に触
師さん> れてクリアされていくことが望ましいわけですが、そのタイミングを
師さん> 何で判断するかが問題です。Berkeley DB の各ファイルのタイムスタ
師さん> ンプを憶えておいて…というやり方でもとりあえずはいいんですが、
師さん> libchise があるご時世にそれはあまりにも泥臭い (^_^;; 気がしま
師さん> す。

師さん> と言うことで、文字素性 db の全体あるいは部分のバージョンやらタ
師さん> イムスタンプやらを調べてくれる API なり何なりがあると、将来的
師さん> にうれしい気がします（libchise にはまだないですよね？　すでに
師さん> あったらすいません）。もっとも問題は実装よりも、何を以て db 全
師さん> 体のバージョンとするか、とか、どういう表現にするか、とかいうよ
師さん> うな面倒そうな点にあるような気がするので、とりあえず今は問題提
師さん> 起ということにしたいと思います。

問題提起ありがとうございます。

自転車操業に拍車がかかっていて進展してないのですが、libchise の中期目
標（うう、いやな単語（意味不明））としては、multi data source 化 +
multi backend 化を考えてます。今は単一の data source しかないのですが、
これを複数化すると共に、Berkeley DB 以外の DB 形式をサポートしたいとい
うことです。

例えば、(a) /usr/local/libexec/chise/ にシステム標準 DB があり、(b)
/usr/local/var/chise/ にサイト共有 DB があり、(c) ~/.chise/ に個人用 
DB があり、(d) http://wiki.chise.org/data/ に世界中から共有可能な DB 
があったとします。

この時、(a) はバージョンを定義可能な気がしますが、他のは多分バージョン
という概念ではうまくいかない気がします。

そして、キャッシュの同期の問題なんですが、(a)〜(d) を含む一般的な状況
で同期を取るのは諦めるしかないかなと思います。ただ、実用的にこの問題を
解決する手段は考える必要があります（うーむ、分散 DB 屋さんや分散 OS 屋
さんの助けが欲しい所、というか自分で勉強しろというか（でも、貧乏暇無し））。

とりあえず思い付く方法としては、(1) data source（あるいは素性）毎に書
き換え頻度が違うだろうから、次に書き変わるかも知れない時刻を設定ないし
は予測して、フェッチをかけるとか (2) データを書き換えると libchise が 
commit message を発行し、アプリケーションはそれを受ける call back を
設定可能にするというようなものがあります。(1) は WWW 日記アンテナみた
いなものですから、world wide な DB にも適用可能でしょう。(2) は実用的
には local なものに限定されるでしょう。


ところで、キャッシュをどうとらえるかという問題もあります。例えば、
XEmacs CHISE には on memory DB があって、これがキャッシュの役割を果た
してます。ただ、これは陽に reset-char-attribute-table をかけないとキャッ
シュがクリアされません。これはキャッシュと考えるといまいちなんですが、
Emacsen の buffer とか cvs の working directory のようなものだと考える
と、これで良いような気もします。

ところで、libchise に現在の XEmacs CHISE の on memory DB のようなもの
を入れたらどうかという気がしてるんですが、この場合、on memory DB を
BerkeleyDB とは違う DS-type の data source として扱うのが奇麗かなと思っ
てます。そして、２つの data sources を関連づける一般的な機構を入れれば、
on memory DB をキャッシュにするだけでなく、(b) や (c) ような local DB
を (d) のような world wide な DB のキャッシュのように扱うことができる
気がします。

また、cvs のアナロジーでいえば、conflict をどうとらえるかという問題が
あると思います。on memory DB をキャッシュと考えると、外部 DB が正しい
訳ですから、conflict した時には on memory DB を消すことになる訳ですが、
一般にはポリシーに依存すると思います。そのため、cvs のように複数の 
data source 間の compare をかけるような機能がいるなあと思ってます。た
だ、通常は優先順位を付けるのが良いかなと思います。今考えてるのは、UNIX 
の mount のように上にかぶせてくモデルで、これを現在導入中の domain と
関連づけたいと思ってます。

思うに、手元のデータを信用して、なかったら遠くのデータを見に行くという
のが自然かなと思うので、この点でいえば、原則として近いものを消さないと
いう風にデザインするのが良いかなと思います。その上で、不審なデータを発
見したら他のデータと compare をかけるという感じになるのではないかと思
います。あとは、貴重なデータじゃなければ記憶領域を圧迫する場合にお好み
でクリアするという感じでどうでしょうか。


師さん> # 最近、次の Java には依拠する Unicode のバージョンを返す API 
師さん> # がつくらしい、という話を耳にしたので。

なるほど。

ちなみに、Unicode のバージョンは CHISE 的には domain で扱うのが良いで
しょうか。また、その場合、バージョンの情報は domain に対するメタデータ
（例：@unicode-4_0*sources）になるのかな。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======