Mac OS X 10.4で整備されたCore Data。NeXTstepからMac OS Xに引き継がれなかった最後のピース「手軽なデータベースアクセス」機能が整ったものとして（個人的に）高く評価している。
実体はSQLiteという夢も希望もないただのSQL RDBMSだが、これをラッピングしてCocoaアプリケーションから利用できるようにしてあるのがCore Dataだ。アプリケーションやアプリ開発者の側ではとくにデータベースの管理や（RDBの）ユーザー管理について関知する必要はない。このへんは（てきとーに）抽象化されており、細かいことを考えなくてよいので便利だ。
高速ファイル検索のSpotlightは、このCore Dataの分かりやすい使い方のひとつだが、プログラム開発者にとってはSpotlightもさることながら、Core Dataそのものがプログラムから利用できることの意義が大きい。
面倒なことを考えずにデータを突っ込んでおける「容れ物」が用意されたわけで……今後、AppleはこのCore Dataをローカルのデータの入れ物としてだけではなく、ネットワーク上で相互に参照できるような入れ物として「見せる」ようにしていくのだろう。
データベースという観点からすれば、ローカルだろーがネットワーク上のDBだろうが透過的にアクセスできてしかるべきだが、ネットワーク管理やユーザー管理の問題が煩雑にならずまとめてスマートに扱えるようにするのがAppleの腕の見せ所だ。
これまでは、ちょっとしたアプリケーションでRBDMSを使いたくても、エンドユーザーの環境にインストールするのが面倒だとか、管理面で大変だとか、すでに同種のRDBMSがインストールされていたらどーするだとか、セキュリティ上面倒を起こしそうだからエンドユーザー環境に入れたくないとか……そういう数あまたの理由でRDBMSを前提としたアプリケーションは（個人的には）あまり作ってこなかった。遅くてもファイルメーカーProのほうが運用が楽だとか、そういう話になることが多いというのも事実だ。
そんなことを考えていると、同様に管理が面倒くさいものとして……ローカルcgiのことが思い浮かぶ。SQLiteの存在を抽象化したように、ローカルcgiを抽象化するレイヤーもOSに備わっていてしかるべきではなかろうか。個人的にはメーカーに対してずっと以前から希望してきたものだが、そういうニーズはあまり多くはないようだ。
話がすっかり脱線してしまった。このCore Dataをベースとしたアプリケーションに対してAppleScript Studioをチャンポンにしたプロジェクトを作るという話を先日書いたばかりだ。Core DataのDBとデータのやりとりを行うのに、TableViewにbindされたText Fieldを経由すれば大丈夫ということが分かった。ここまでが「前回までのあらすじ」だ。
この結果、現在ユーザーがアプリケーションのGUI（Table View）上で選択している行の内容については、AppleScript側からデータを取り出したり変更したりすることができるようになった。これができるようになっただけでも大きな進歩ともいえるが、そもそもユーザーが何のデータも選択していなかったらお手上げなわけで、それはそれで困る。
そこで、Core Dataのデータベースに直接アクセスしたいという話が当然のように出てくるわけだが……Core DataはObjective-Cによるプログラミングを前提としたフレームワークであるため、利用するにはObjective-Cを理解することが前提となる。
AppleScript系のデベロッパーとしては、Objective-Cの話なしでCore DataのDBにアクセスする手段が欲しいという話になる。簡単な構造のデータベースを手っ取り早く作ってはテストしているのだが、凝ったものになると今のところはさっぱり分からない。
Appleから提供されているドキュメントはすべてObjective-Cの開発者向けに書かれているものなので、AppleScriptの開発者はここでAppleのドキュメントを当てにできない。
しばし熟考した末に、Core Dataという抽象化された存在ではなく、データベースの実体ファイルそのものにアクセスすればよいことに気づいた。
Core Dataアプリケーション（マルチドキュメントではなく、いわゆるSDIタイプ？）を走らせると、データベースは~/Library/Application Support/アプリ名/のディレクトリに保存される。デフォルトのデータベース形式はXMLだ。XMLならただのテキストだし、AppleScriptで利用できるParserも用意されている。
GUI上に表示されているものをいちいちテキストとして評価してリストに組み立てるとか、そういう面倒な作業を行わなくてはならないわけだが、それでもデータにアクセスできることの意義は大きい。
究極的には、AppleScript側から指定データベースの指定レコード（あるいは全レコード）をリスト型変数として取得できるようにするObjective-Cのプログラムが必要になるが、いまはとりあえずこんなところで十分だろう。もし、具合がよろしくないということであれば、Core DataのDBにアクセスするOSAX（AppleScriptの拡張命令書類。実行環境にすべてインストールしておく必要がある）を併用すればよいだけの話だ。
……という話を英訳してUSのAppleScript Studio MLに投げようかと思ったのだが、面倒くさいので要約して英訳して投げておこう。多分、２〜３行になる、、、、
Core Dataだけの話題を扱ったMLがあるとよいのだが、Objcetive-C系の開発者とAppleScript系の開発者の間ではまったく話が通じない状態なので、同様の構造になっているAutomater Dev MLよろしく「話がまったくはずまないML」になってしまう可能性は高い。
