RDBC = Ruby Database Connectivity.

ここにあるファイル群は、RDBCのための簡単な見本です(と思っています)。

RDBCはRuby Database Connectivityを意味します。
その名から想像される通り、JavaのJDBC
のようなものを目指していて、また構成も似通っています。
クラスやメソッドの名も、割とそれっぽくしています。
なので、RDBCを使ったりDriverを作ったり改造したりしたいと
思ったとき、JDBC用の教科書はRDBCへの理解を助けるかも知れません
(恐らくワタシよりJDBC用の教科書のほうが、より良く貴方を助けるでしょう(笑))

現状では実際のDatabaseサーバーに接続するためのBridgeとして
Oracle用とPostgres用のBridgeが用意されています。
それらのBridgeから、prototypeらしく(?)、諸兄によって書かれた
既存のRubyラッパーをそのまま呼ばせて貰っています。
つまり、Yoshidaさんのoracleモジュールと
matzさんのpostgresモジュールを、それぞれ使っています。

RDBCでは、そのユーザーが自分でnewを呼ぶ必要があることは(殆ど)ないです。
他のオブジェクトのメソッドによって非明示的にnewされるオブジェクトが殆ど。
ごく簡単な使用例は、各scriptの最後あたりに直接書かれている。

RDBCはSQL文の存在を隠蔽していない(JDBCと同様)。
SQLを取り扱うのを便利にするために各種クラスが用意されているだけである。



DriverおよびBridgeについて:

Bridgeは、RDBCユーザーが直接使う幾つかのクラスと
RDBMSのそれぞれのクラスに対応するであろう機能との
「間を取り持つ」クラスである。たとえばStatementBridgeは
Statementに関連するRDBMS側の機能に直接アクセスする
ためのクラスである。そのためRDBMS種依存の処理は
xxxBridgeクラス(と、Driverクラス)に持たせることになる。
実際には、xxxBridgeクラス(と、Driverクラス)は、
RDBC1モジュールの中にある抽象(半端雛形)クラスを
継承し具象化することで実装されることを仮定している。

具象化の例として、postgres用とoracle用のDriverを作成した。





各オブジェクトの関連について:

RDBC各種オブジェクトはCompositeクラスを使って
親子関係(しばしば一対多)のTreeを構成する。
構成を図示するならば以下のようになる。

Driver
| Connection
| | ConnectionBridge
| | Statement
| | | StatementBridge
| | | ResultSet
| | | | ResultSetBridge
| | | | ResultSetMetaData
| | | | | ResultSetMetaDataBridge

ただしBridgeは親と一対一関係である。
またBridgeは示した通り全てがTreeのLeafである。

Composite#closeは、親から子へ伝播する。
そのため、ツリー上位でcloseすればそれより下位では
RDBCオブジェクトは無効化され、Bridgeで
対応するRDBMSリソースが解放される
(Bridgeについては、そのようにDriver作者が作ってくれるのを希望する)。

RDBCアプリ終了時には、DriverManagerが
今存在する全部のDriverに対してcloseをするので
つまりRDBCオブジェクトは全てcloseされることになる。
ユーザーは明示的にcloseを行う必要はない。





ToDo:

BLOB,CLOBなどと呼ばれている「巨大な」データを
RDBサーバーとscriptの間でやりとりする方法を、用意すべし。
Stringでpackしてしまうにしては大き過ぎるバイト列は、
そのデータを(ファイルのように)望むだけ少量バイトづつ
読み書きできるようになると良いだろう。つまり、IOに似た
readおよびwriteメソッドを持った「Stream」クラスが欲しい。
そしてResultSet#getDataが必要に応じてこれを返すようになれば良いだろう。
StreamクラスはRDBC(RDBアクセス)のみならぬ広い用途があると思われる。

ResultSet#each はRubyの常識として存在するべきでは?

TOYでないものを作る。皆さん作ってください(^^;
Driverは必要に応じてC拡張ライブラリとして書かれることも有り得るはず。

「JDBCに似たクラスライブラリ」を名乗るにしては、
実際に実装されたクラスおよびメソッドが少なすぎる。

そして恐らく他に無数。


20000526 NAKAMURA AKIFUMI (BXQ04723@nifty.ne.jp)