_rowid longlong,
_timestamp timestamp,
_version long
の三つである。このうち_rowidはprimary keyとして定義されnot null, unique indexedでserial化されているので、行を挿入すると自動的に新しい一意な値がセットされる。
OpenBase を使ったアプリケーション開発ではPKとしてこの_rowid を使い、他のテーブルからリレーションを張る場合の FK にセットするのが常道だ。
だが、他の二つの属性は使ったことがなかった。
この二つの属性はOpenBase のシステムが自動的にメンテナンスしてくれる情報になる。
まず、新しい行が作成された時に、この二つの列は_timestampに現在時刻が_versionに1がセットされる。
そして更新されるたびに、 _timestamp は更新日時に変更され、 _version は+1される。
つまり _timestamp を見れば最後に更新された日時がわかり、 _version を見ると何回更新されたかがわかる。
これは複数のアプリケーションがこのデータを利用している場合に、例えば自分自身が内部的にキャッシュした値が、誰か他のアプリケーションによって更新されたかどうか判断するときに使える。楽観的ロック機構の実現に使われるフィールドなのではないだろうか？
今まで使っていなかったのだが、なんだか使えそうな気がして調べてみたらそういうことがわかった。
openbase 1> create table test (
openbase 2> author_id integer,
openbase 3> name varchar(128)
openbase 4> );
openbase 5> go
SQL executed - 0.743 seconds
openbase 1> insert into test (author_id,name) values (1,'Queen');
openbase 2> go
1 row inserted - 0.044 seconds
openbase 1> select * from test;
openbase 2> go
Data returned... calculating column widths
_rowid author_id name
--------------------------
1 1 Queen
--------------------------
1 rows returned - 0.003 seconds (printed in 0.008 seconds)
openbase 1> select _rowid,_timestamp,_version from test;
openbase 2> go
Data returned... calculating column widths
_rowid _timestamp _version
--------------------------------------
1 2011-08-18 16:07:48 +0900 1
--------------------------------------
1 rows returned - 0.001 seconds (printed in 0.005 seconds)
openbase 1> update test set name = 'King' where author_id = 1;
openbase 2> go
1 row updated - 0.065 seconds
openbase 1> select _rowid,_timestamp,_version,author_id,name from test;
openbase 2> go
Data returned... calculating column widths
_rowid _timestamp _version author_id name
-------------------------------------------------------
1 2011-08-18 16:14:25 +0900 2 1 King
-------------------------------------------------------
1 rows returned - 0.002 seconds (printed in 0.007 seconds)
openbase 1>
