4. Cursor

4. Cursor

Cursor（カーソル）を使うと、Queryにおける検索ポジションを覚えておくことができます。次回の検索時には、そのポジションの次からエンティティを検索できます。例えば、ページ単位で検索内容を表示して、「次のページ」ボタンのクリックによって次の検索結果を表示する場合などに便利です。

検索を開始するポジションは、FetchOptionsのoffsetによって指定することもできますが、この場合の検索処理は、内部的には、先頭からエンティティを読み取ってoffsetのポジションまで読み飛ばしているに過ぎません。したがって、offsetの値が大きくなるに従ってパフォーマンスが低下します。

【リスト12】: カーソル使用での検索（ビーンズ・メソッド）

リスト12における（1）から（4）が、カーソル処理に関係した処理です。

（2）では、FetchOptions.BuilderのstartCursorメソッドによって、カーソルの開始位置を指定します。なお、以前はcursorメソッドを使っていましたが、現在は非推奨（deprecate）になっているので、startCursorを使います。

CursorのfromWebSafeStringメソッドは、引数に指定した、エンコードされているcursorを、文字列にデコードします。引数で指定されるcursorは、（1）のrevOrdCursorメソッドにおいてクライアントから引数で渡されるものです。初回の検索ではブランクになっており、エンティティの先頭から検索されます。クライアントからの2回目以降のリクエストでは、cursor値が設定されているため、cursor機能が有効になります。

なお、データ数が少ないことから、limit(3)の指定によって3件ずつエンティティを表示しています。実際のアプリケーションでは、もっと大きな値指定になるはずです。

（3）では、QueryResultList>>のインスタンスordにgetCursor()メソッドを適用し、listの最後に、次のエンティティ値を指すカーソルを返します。CursorのtoWebSafeStringメソッドは、cursorをエンコードします。

最後に（4）で、取得したcursorを、検索値と一緒にクライアントに送信します。

【リスト13】: カーソル使用での検索（Webクライアント）

カーソル参照  <input type="button" id="revstart" value="カーソル参照"/>

リスト13は、カーソル検索を実施するWebクライアントです。画面上で「カーソル参照」ボタンをクリックすると、（2）において、DWRメソッド形式でビーンズのrevOrdCursorメソッドにリクエストが送られます。

初回のリクエストでは、（1）において、引数cursorはブランクになります。ただし、2回目以降のリクエスト（「カーソル参照」ボタンのクリック）では、（3）において取得されたカーソルが（2）メソッドの引数としてサーバーに送られます。それぞれの場合のビーンズ側処理は、リスト12で説明した通りです。

[カーソルを使用した画面表示]

最後に、リスト12、リスト13のプログラムを使ったたカーソル利用の画面表示を紹介します。

画面11～画面14は、「カーソル参照」をクリックした際の、画面表示の変化です。クリックするごとに3件ずつ、startCursor位置からのエンティティが表示されています。

今回で、この連載は終了です。分散キー・バリュー・ストアには、以前のRDBと比較したメリットとデメリットがあります。特に、メリットについては、Low-Level APIを使うことで、その特徴を生かせるようになります。筆者は、分散キー・バリュー・ストアは、実際のアプリケーションでじゅうぶんに使用に耐え得るデータ・ストアであると思っています。読者の方の評価はいかがでしょうか。