本25本目の投稿で、はまってシリーズを一旦終了し「まとめ」ます。
当ブログの単一テーマによる投稿としては、過去最長のシリーズになりました。
表現の統一もそこそこ(ダメダメっぽ。)でしたし、訂正や追記も多くなりました。結果、ボロボロであったという印象は拭えません。
IndexedDB APIへの理解も半端に、俯瞰もできないまま始めて、検証しながらの執筆でしたから致し方ないでしょう。(と言い訳。)
統一感のある冊子を作成できる機会でもあれば幸いですが、あまりにもマイナーなIndexedDBの存在を鑑みるとそれも望めないでしょう。
え?同人誌?コミケに打って出るか?うーん、ない。
まあ、誰かの役に立つのであれば、ありかもしれません。でも編纂作業したくないなあー。そんな期待?を込めつつまとめ?ていきます。
まずは、はまってシリーズ全体の流れを記述しておきます。
Outline
IndexedDB(Indexed Database)を学習し始めた話題と、データベースの生成とイベントの大枠について
データベースの生成もしくはアップグレードに伴うイベントの受け取り枠と、データベースの削除について
オブジェクトストアの生成とそのオプション(キーパスとキージェネレータ)の話題、そしてオブジェクトストア生成のトランザクション発動について
データベースのアップグレードとオブジェクトストアの削除について
(注意)
これ以降、インデックスキー(補キー)の出現までは、データベースの開始が成功したイベント枠中のレコード操作になる。
データベースの開始が成功したイベントにおいて、オブジェクトストアのトランザクション発動とレコード格納について
オブジェクトストアへのレコード格納における二種のメソッドの比較と、レコードの削除について
オブジェクトストアにて、キージェネレータのオン指定による動作と、レコード一掃について
キージェネレータのオンオフと、キーパスの指定による動作について
キーパスとキージェネレータの指定についての「まとめ」と、キージェネレータをオフにしてのレコード操作(格納、参照、削除)について
キージェネレータをオフで、キーパスを配列にした場合のレコード操作(格納、参照、削除)の検証について
ラングオブジェクトの生成について
データベースの開始が成功した処理の最後に、必ずデータベースを閉鎖メソッドを記述することについて
オブジェクトストアに複数レコードを格納して、ラングオブジェクト利用によるレコード操作(カウント、複数参照)について
インラインキーとアウトオブラインキーモードについての訂正と、ラングオブジェクト利用によるレコード操作(複数の格納、参照、削除)の検証について
カーソルの効果、ならびにカーソル生成と基本利用、パラメータによるカーソル移動について
ラングオブジェクト生成メソッドの訂正版について
カーソルの応用?利用によるレコードの削除(バックアップ取得と削除)とカーソル移動について
カーソルの応用?利用によるレコードの更新(バックアップ取得とアップデート)とカーソル移動について
(注意)
ここまでのキーは、プライマリキー(主キー)のことです。このあとからインデックスキー(補キー)が現れます。このあとは主キーと補キーと表記します。
補キーの登録指定パラメータと、オブジェクトストア生成のトランザクションによる補キーの登録について
データベースのアップグレートイベント内で、既存オブジェクトストアのトランザクションによる補キーの追加登録と削除について
(注意)
これ以降は、データベースの開始が成功したイベント枠中のレコード操作にに戻る。
補キーによるラングオブジェクト利用しての個別レコード参照や複数レコード参照と、カウントについて
補キーの登録指定パラメータ、特に一意(ユニーク)とマルチエントリーの指定による動作について
補キーによるカーソル生成と基本利用、カーソル移動について
補キーによるカーソルの応用?利用によるレコードの操作(バックアップ取得と削除もしくはアップデート)とカーソル移動について
つづいて、IndexedDBの利用について、ひとつのアイデアを紹介します。
Module
IndexedDBの動作について紹介してきましたが、これら機能をまとまった状態で取り回すにはどうしたらよいのか?思案のしどころです。
はまってシリーズを投稿しながら、さまざまに試行錯誤してきました。
おかげで「私なり」の手法に至り、これなら行けるのではないかという落とし所を得ましたので紹介いたします。
ただし、具体的にデータベースの運用を行なっている訳ではないので、大枠だけのお披露目になります。
何某かの参考になれば幸いです。
個人の開発ライブラリについて
現在、個人の開発ではjQueryなど既存のライブラリは使っておりません。
Javascriptのお約束だって手いっぱいなのに、他の人が作ったお約束まで面倒見てられないのと、プラットホームの内実を知らずに利用するのが個人的に許せないということもあります。
全てとは言いませんが、せめてウェブブラウザーに用意されている仕組みぐらいは自らのアンダーコントロールにすることを希望してます。
つぎのスクリーンショットは、個人で開発し、利用しているモジュールのライブラリになります。

jQueryのような謂わゆるライブラリは、hustlePageUtilityModule.jsのように一つのクラスファイルに短絡的なオーダーに応える静的なメソッドを拡充して開発を進めてきました。
簡素なものから始まって、なんやかや20年ぐらい継続して開発してきました。
これらは系統(独断)毎に1クラスを1ファイルの約束とし、開発してます。JAVAでプログラミングを学習した影響からそうしてます。
IndexedDBのモジュールについて
昨年2023年の暮れからとりかかったIndexedDBについても、当初は普通のライブラリから始めました。
ところが、学習を進めて、さらにその成果を備忘のためにブログに投稿していく中で、いままでのライブラリの構成に馴染まないと考えて、構造を工夫しました。
手間はかかりましたが、投稿がいい検証作業になり、堅実なコードになったと期待します。
IndexedDBに関するモジュールは「hustleIDBAgentModule.js」と「hustleIDBExpertModule.js」の2ファイルによって構成され、静的メソッドで構築されてます。クラスを分けたので、自分の約束に従って2ファイルになってます。
名前から、ここでは「Agentモジュール」と「Expertモジュール」と呼びます。
つぎは概念図です。

Agentモジュールについて
データベースを利用する窓口として機能するモジュールになります。
IndexedDBを利用する場合は、このモジュールのインターフェースメソッドを参照します。
また、ラングオブジェクトを生成するメソッドなど、データベースの利用に関するライブラリも備えています。これらはもう一つのExpertモジュールからも必要に応じて利用されます。
インターフェースメソッドは操作目的に合わせて複数用意してあります。それらメソッドへの参照があるとコマンド(キーワード)を挟み込み、二つのモジュールでの操作の振り分けに利用します。
インターフェースメソッドには、必ずコールバックする関数オブジェクトを仕込むことになっており、はまってシリーズでコンソールに返していた情報がコールバックされます。
インターフェースメソッドは、キーワードの数だけあると理解してください。
内部では操作概念毎にメソッドを参照して、キーワードで処理を分岐する算段となってます。
順次、渡された情報が正しいかどうかをチェックして基本的な例外を回避する処理がされます。
Agentモジュールの段階で行える情報チェックに問題がなければ、Expertモジュールのメソッドを参照して実作業に進みます。
Expertモジュールについて
データベースを具体的に運用するモジュールになります。
データベースのアップデートのイベント発火に始まり、オブジェクトストア生成、トランザクション発動、カーソル移動などによるレコード操作の実際が行われます。
内部では操作概念毎にメソッドを参照して、キーワードで処理を分岐する算段となってます。
処理の最後で、受け継がれてきたコールバック関数によって情報が返されます。
ザックリとモジュールの構造の紹介でした。
現在は(これが最適解と祈って、)調整をしながら、IndexedBDを実運用するコンテンツの開発を進めています。そのうち細かい仕様を提示できるかも知れません。
ところで、IndexedDBって排他制御はあるのでしょうか?いまのところ情報に行き当たってません。
まあ、Webアプリケーションの利用にあたって、他のユーザーがローカル情報にコミットすることが想定できませんから…。存在しないだろうと予想しています。
それでは、長きに渡った「はまってシリーズ」は終わります。自分にお疲れ。そかさ。