新しいハード ディスクが年を追って大容量化、高速化するにつれ、アプリケーションが生成するデータも肥大化しています。 ハード ディスクの一般的な用途は、通信文、個人用連絡先、および業務文書などの個人情報の保存です。 このようなアイテムは、現在のところ個別に扱われていますが、あるレベルでは相互関係を持っています。したがって、個人用連絡先リストに載っている相手から電子メールが届き、それが業務に影響して、それゆえに作成する文書が決まるのはまったく自然な流れです。保有するアイテムが多いと、特定のアイテムをプロパティやコンテンツを基に検索するための柔軟で効率的なメカニズムが重要になります。 現在までの、Outlook、Windows 連絡先一覧、Windows Media Player メディア ライブラリなどの保存メカニズムに採用されている、アイテムを保存するテクノロジ、および検索するメカニズムは相互に関連がありません。 しかし、"Longhorn" というコード ネームの Microsoft Windows の登場で、そのような時代も終了です。
"Longhorn" の汎用ストレージ サブシステム "WinFS" (コード ネーム) は、あらゆる種類のデータを保存し、データに単一のメカニズムでアクセスできます。レジストリ、イベント ログ メッセージ、連絡先情報、電子メールなどのデータを保存するために互換性を持たない複数のストレージを利用したり、画像やオーディオなどのデータに複数のフラット ファイルを使用したりしていた OS にとって、これは大きな変化です。"WinFS" はデータベース テクノロジを使用して実装されているので、データ アイテムにクエリを実行するための効率的で柔軟なメカニズム、他のコンピュータのストアにデータをレプリケートする機能、およびバックアップと復元の機能が提供されます。
この資料では、"WinFS" の基本的なアーキテクチャを概観し、データがどのように保存および取得されるのか、およびオペレーティング システムにどのようなサービスが提供されるのかについて説明します。"Longhorn" の大部分がそうであるように、"WinFS" にも独自のマネージ API あるので、そちらについても詳しく説明します。
基本的なアーキテクチャ
データに関して年中発生している問題として、データの量が多すぎて、希望するデータを検索するのが非常に困難であることが挙げられます。 この問題は、一般的なコンピュータにテラバイト単位のハード ドライブが搭載されるようになる近い将来、ますます深刻化するでしょう。 ハード ディスクが大容量化するにつれ、保存するデータ量も多くなり、特定のアイテムを検索することが困難になります。 あるデータを検索するには、特定のアイテムを識別することが前提となります。つまり、アイテムの分類が必要になります。
たとえば、数千点のデジタル写真があるとしましょう。 一般的には、カメラやデスクトップ ソフトウェアがこの写真に通しで名前を付け、データのカタログが作成されます。そしておそらく、写真は撮影日ごとにフォルダに格納されます。 このスキーマで特定の写真を検索するには、撮影日と写真の番号を覚えておく必要があります。 いずれの情報もわからない場合、写真のサムネイルを目視することを余儀なくされます。 もちろん、手間を惜しまないのであれば、写真をデスクトップにダウンロードするごとに、名前を付けていくこともできます。 Win32 のファイルとフォルダのシステムのような、大まかな制御しか行われないシステムでは、必要なデータをすべて保存できるだけの柔軟性がありません。
この溝を埋めるのがデスクトップ ソフトウェアで、カメラの設定、光の状態、および各写真の一般的な説明など、上記以外の説明用のプロパティを保存するカタログを生成できます。そのようなソフトウェアは当然データベースを利用して実装されていますが、重要なポイントは、それがファイル システムを補完する機能を果たしていることです。写真の説明、つまりメタデータは、実は写真のオブジェクトの構成要素だと言えます。 デジタル写真の場合、画像ファイルの EXIF (Exchangeable Image File Format) ヘッダーにも情報が格納されています。 このヘッダーには、撮影時に取得した情報が格納されます。 このメタデータを検索対象にするには、検索するそれぞれの写真からメタデータを抽出してクエリ条件と比較するクエリ エンジンが必要です。 高機能の写真管理プログラムであれば、写真をデスクトップに転送するときに EXIF 情報を抽出して、追加のメタデータとしてデータベースに格納します。
これこそ "WinFS" に適した分野です。"WinFS" ストアに格納されるものはすべてアイテムと呼ばれ、各アイテムにはあるスキーマで記述されたメタデータ プロパティがあります。 このスキーマに従うアイテムは、"WinFS" ストアに .NET オブジェクトとしてシリアル化されて保存されます。アイテムには、T-SQL ビューからアクセスできます。T-SQLを使って、アイテムのプロパティにアクセスできるのです。ディスクに保存されている写真を検索するには、ストアに対して、画像アイテムのメタデータ プロパティ、EXIF ヘッダーから取得した情報、およびファイル情報 (作成日、画像を構成する実際のビット数など) を条件にクエリを実行する必要があります。
図 1 "WinFS" のファイル
図 1 は、"WinFS" におけるアイテムの概念的なアーキテクチャを示しています。 各アイテムは、コンテナ (containment) フォルダに格納されます。このフォルダは、アイテムの有効期間の制御に使用します。フォルダ自体もアイテムであり、各フォルダは、別のフォルダに格納する必要があります。 この包含規則の唯一の例外が、ルート コンテナ フォルダです。 アイテムを格納するボリュームは、アイテムのコンテナとしては最大の自律的なコンテナです。 それぞれのコンピュータで、"WinFS" サービスはこのボリュームに対して機能し、アイテムの保存、削除、変更、および参照に使用されます。
"WinFS" ストレージ
"WinFS" では、アイテム テーブルの T-SQL ビューがアイテムの型別のビューで表示されます。 ストアのセキュリティやデータの一貫性を保つために、ビューからはデータを読み取ることしかできません。 データを変更するには、ストアド プロシージャを使わなければなりません。 たとえば、次のステートメントを実行すると、コンピュータのメディア ライブラリにあるすべてのトラックから、要求した情報が返されます。
SELECT Artist, Title, Album FROM Audio.[Track!V1]一部のオブジェクトは、他のオブジェクトへの参照を含んでいます。 たとえば、Track オブジェクトには Authors というメンバがありますが、Authors は Author オブジェクトのコレクションであり、各 Author オブジェクトにはそのトラックを作成したアーティストの名前を示す DisplayName プロパティがあります。 特定のアーティストが作成したすべてのトラックを検索するクエリを構築して、個人用のアドレス帳との相互参照により、保有しているトラックのアーティストの携帯電話番号を控えてあるかどうかを確認することが可能です。 (もちろん、著名人が名を連ねるアドレス帳を持っていればの話ですが)
すべての人がデータベース開発者で、複雑な選択クエリを構成できるとは限りません。そこで、"WinFS" では高レベルな API を利用して、アイテムの挿入、削除およびクエリを簡単に実行できるようになっています。
"WinFS" 型と .NET 型
マネージ API を使用して "WinFS" アイテムにアクセスするときは、.NET オブジェクトを使用します。 "WinFS" アイテムは、その型ごとに対応する .NET Framework クラスがあります。クラス階層には System.Storage.Item があります。 Item 型には ItemID_Key プロパティと GUID があり、これによって "WinFS" アイテムが識別されます。 "WinFS" オブジェクトを取得するときは、API が、対応する .NET 型をその "WinFS" オブジェクトのメタデータで初期化して返します。 ItemID_Key 値が同じ 2 つのアイテム インスタンスを取得した場合、異なる .NET 参照があったとしても、いずれもストア内の同一アイテムを参照しています。 2 つの "WinFS" オブジェクトを比較するときは、ReferenceEquals を使用するのではなく、対象となっているアイテムの ItemID_Key の値どうしを比較することが重要です。
"WinFS" 用語において "WinFS" の型とは、アイテム、ネストされた要素、スカラのいずれか、またはそれらの集合を構成要素とするアイテムです。 アイテムは一貫性を持つまとまった単位なので、アイテムをコピーまたは削除すると、アイテムのすべての要素もコピーまたは削除されます。 ネストされた要素はアイテムの一部としてのみ存在することが可能です。 この動作は、.NET での機能と異なります。 たとえば、System.Storage.Contacts.Person オブジェクトの PrimaryName プロパティは、FullName という型のネストされた要素です。 同じ PrimaryName を持つ 2 つの Person オブジェクトを作成する場合は (たとえば、同名の父と息子など)、それぞれの Person オブジェクトに 1 つずつ FullName オブジェクトを作成する必要があります。 2 つの Person オブジェクトに対し同一の FullName オブジェクトを使用している場合、その Person オブジェクトは .NET オブジェクトとしては有効であるものの "WinFS" オブジェクトとしては有効ではないため、ストアに保存すると例外が発生します。
"WinFS" マネージ API
図 2 は、"WinFS" の全体的なアーキテクチャを示しています。 "WinFS" ストアにはさまざまな API からアクセスできます。今回のリリースでは、SQL Server Provider を使用した ADO.NET、ネイティブ コードを使用した OLE DB、COM ベースの API、およびマネージ API を使用できます。 一般的に、開発者は T-SQL よりも API を使用することになりますが、T-SQL を使用すれば可能なことでも、API では不可能なことも多数あるので、T-SQL からもアクセスが行われるでしょう。
図 2 "WinFS" アーキテクチャ
.NET 専門の開発者であれば、汎用的な WinFS API が含まれている System.Storage アセンブリにある WinFS API を使用します。 また、"Longhorn" の標準の型 (Track、Image、Folder、Message など) に使用する API が含まれる System.Storage.Schema アセンブリも使用します。 "WinFS" アイテムに定義されている共通言語ランタイム (CLR) 型の他、System.Storage.Schema アセンブリにはアイテムのデータ モデル マッピングが含まれています。 このマッピングは、"WinFS" に対し、アイテムへのアクセスに使用するデータ ソース、およびマネージ型のプロパティからデータ ストア テーブルのフィールドへのマッピングを示します。 WinFS API の深層部では、このマッピング情報を使用して、ストアのアイテムにアクセスする T-SQL クエリが構築されます。
すべての WinFS API コードは ItemContext で実行する必要があります。 ItemContext にはさまざまな意味があります。 まず、ストアへの接続を確立する必要があります。ItemContext がアクティブな間は、この接続はアクティブです。 また、ItemContext はデータ接続なので、トランザクション機能が提供されます。 ストアに対していくつかの変更をアトミックトランザクションの単位にすることができます。 さらに、ItemContext により、検索対象のアイテムを定義することで作業範囲が明確になります。
最初に実行する必要がある操作は、静的な Open メソッドで ItemContext を開くことです。 パラメータを持たない Open メソッドはすべてのアイテムのコンテキストを開きますが、他のオーバーロードによってコンテキストの範囲を制限できます。 "WinFS" では、ボリュームと、円記号で区切ったフォルダへのパスの両方を指定できる名前付け手法が使用されます。
ItemContext では BeginTransaction および EndTransaction によりデータ接続にアクセスできます。 BeginTransaction は、新しいトランザクションを作成し、Transaction オブジェクトを返すメソッドです。 これを実行すると、ストアに対して行うすべての変更は、EndTransaction を呼び出すまでこのトランザクションの影響下で実行されます。ストアに対して行ったすべての変更は、アトミックトランザクションとして処理されます。
また、ストアへのアクセスを終了するときは、ItemContext に対して Close を呼び出すことでデータ接続を解放することも指摘しておきます。 ストアに変更を行った場合、Update を呼び出して変更がストアに確実に保存されるようにします。 この "WinFS" プレリリース版では、Folder オブジェクトを作成したら、フォルダにアイテムを格納する前にオブジェクトを保存する必要があります。 これを行うには、Folder.Save を呼び出します。このメソッドは単に ItemContext.Save を隠蔽しているだけです。
フォルダにアイテムを格納する
もっとも広範なレベルでのオブジェクトの分類は、フォルダによって実現されます。 "WinFS" フォルダはアイテムを格納するために使用されますが、Win32 におけるファイル システム フォルダの概念とは異なり、1 つのアイテムを複数の "WinFS" フォルダに存在させることが可能です。 独自のフォルダ階層を作成する場合は、最初に既存の階層にフォルダを追加します。 これを行うには、コンストラクタのパラメータとしてコンテナ フォルダ オブジェクトと新しいフォルダ名を渡して新しい Folder オブジェクトを作成します。 コンテナ フォルダは既存のどのフォルダでもかまいません。ルート フォルダを取得し (Folder.GetRootFolder を呼び出すだけです)、ルート フォルダに含まれるすべてのフォルダ オブジェクトに繰り返し処理を行うことで階層全体を処理できます。 通常は、最上位のフォルダにはアイテムを格納せず、代わりに下位階層のフォルダを使用します。
各ボリュームのルート フォルダには既定で System Data、Volume、Schema、および Store Information の 4 つのフォルダが格納されています。 ユーザーが作成するフォルダは、System Data の下位に格納します。 これを行うには、Sytem Data フォルダを検索して開き、その下にフォルダを追加します。 ただし、WinFS API を使用して、ユーザーのアイテム用に特に割り当てられているフォルダに簡単にアクセスする方が簡単です。 静的メソッド UserDataFolder.FindMyUserDataFolder は System Data の下にある現在のユーザーのためのフォルダを返します。アイテムの型によっては、独自の標準フォルダが用意されているものもあります。 たとえば、UserDataFolder.FindMyPersonalContactsFolder メソッドは、Personal Contacts というフォルダを返します。
適切なフォルダにアクセスしたら、Folder.AddMember メソッドを使用してアイテム (および他のフォルダ) を格納できます。 フォルダからアイテムを削除するのも、同様に簡単です。Folder.RemoveMember メソッドを呼び出し、アイテムまたはアイテム名のいずれかを渡します。 フォルダにアイテムを格納すると、保持リンクと呼ばれるリンクが使用されます。 フォルダ オブジェクトも単なるアイテムの 1 つであり、格納しているアイテムごとに保持リンクが設定されます。保持リンクは特殊なリンクで、参照先アイテムの有効期間を決定します。また、アイテムの各保持リンクは参照カウンタとして機能します。 保持リンクはアイテムにのみ適用できます。そしてこれこそが、アイテムとネストされた要素との違いを特徴付けています。 アイテムのすべての保持リンクを削除すると、アイテムも削除されます。 "WinFS" フォルダは、格納するアイテムの型に対する制約がありません。 つまり、[Summer Vacation 2003] というフォルダがあるとすると、このフォルダには休暇中に撮影したすべての写真、予約確認の電子メール メッセージの他、マドンナの「Holiday」の WAV ファイルまで格納できるということです。
フォルダのアイテムには簡単にアクセスできます。フォルダ アイテムには、Link アイテムのコレクションを実体とする Members というプロパティがあります。 各 Link アイテムは保持リンクであり、その SourceItem プロパティを使用すると適切なアイテムにアクセスできます。 さらに、Folder クラスには、指定した名前が付けられているメンバや、特定の型のメンバを取得できるメンバがあります。
アイテムの検索
コンテキストを作成し、アイテムを格納するフォルダを決定したら、次はアイテムにアクセスする必要があります。 最も簡単にアクセスする方法は、図 3 に示すように、フォルダのすべてのアイテムに繰り返し処理を行い、アイテムを 1 つずつ確認する方法です。 FindResult オブジェクトには、GetAllMembers で実行されたクエリの結果が格納されます。この結果にはフォルダのすべてのアイテムが含まれます。 次に、それぞれのアイテムについて Item 型の CLR オブジェクトが作成され、アイテムが FindResult オブジェクトに格納されます。 GetAllMembers はちょっと大雑把な API ですが、次に示すように GetAllMembersOfType を使用すれば、クエリを少し洗練して、フォルダの Person アイテムのみを返すようにできます。
using (FindResult result
= myDataFolder.GetAllMembersOfType(typeof(Person)))
{
foreach(Person person in result)
{
if (person.DisplayName == "Richard Grimes")
{
// ここで person を使用する
break;
}
}
}
Find メソッドの 1 つにフィルタを渡して、さらに検索を絞り込むことができます。
Person person = (Person)myDataFolder.GetOneMemberOfType( typeof(Person), "DisplayName='Richard Grimes'");
このメソッドは、先ほどのコードの作業をすべて行います。 特定のフォルダから、フィルタ文字列に指定したプロパティ値が設定されている特定の型のオブジェクトが検索されます。 フィルタ文字列の記述には、WinFS OPath という新しいクエリ言語を使用します。OPathを使うと、型のプロパティをチェックするフィルタを作成してメソッドに渡すことができます。ここでは、Person.DisplayName プロパティにチェックを実行します。 検索の際、見つかった各 Person オブジェクトの DisplayName プロパティが抽出され、その値と指定したリテラル文字列が比較されます。
WinFS OPath は柔軟性に優れており、&& 演算子および || 演算子で複数の条件を付加することが可能です。 さらに、次のように like 演算子も使用できます。
FindResult result = myDataFolder.GetAllMembersOfType( typeof(Person), "DisplayName like 'R% Grimes'");実行すると、DisplayName が "R" で始まる名と "Grimes" という姓から構成されている Person アイテムがすべて返されます。
一部のプロパティはコレクションになっています。そこで、WinFS OPath には、コレクション内のアイテムのプロパティをチェックできる構文も用意されています。 たとえば、Person クラスには PersonalNames というプロパティがありますが、これは FullName オブジェクトのコレクションです (1 人で複数の名前を使い分ける人がいることに対応しています)。 個人名として 1 つでも Grimes 姓を名乗るすべての人を検索する場合、次の構文を使用できます。
FindResult result = Person.FindAll( ctx, "PersonalNames[Surname='Grimes']");
この例の角かっこは、PersonalNames がコレクションであり、そのアイテム 1 つずつに対して Surname プロパティをリテラル文字列と比較することを示しています。 この例で使用した Person.FindAll は、指定したコンテキストのすべての Person アイテムを検索する静的メソッドです。 すべてのアイテム クラスは、オーバーロードされた FindAll が Item クラスから継承されています。さらに、フィルタ条件を満たすコンテキストから指定した型のアイテムを 1 つ返す FindOne メソッドが、すべてのアイテム クラスに用意されています。
アイテム クラスでは、アイテムの ID を基にアイテムを検索することも、特定のカテゴリを持つアイテムを検索することもできます。 カテゴリとは、実はアイテムに付けられている名前です。 Item クラスには Categories というプロパティがありますが、これはアイテムに付随するすべてのカテゴリのコレクションです。各カテゴリは CategoryRef オブジェクトです。 Categories にはカテゴリ名を表す Key プロパティと、カテゴリを識別する GUID を表す Type プロパティがあります。 カテゴリは、独自に作成することも、GeneralCategories 型の静的メンバとしてあらかじめ定義されているものを使用することもできます。 アイテムにカテゴリを追加するには、新しい CategoryRef オブジェクトを作成し、Category プロパティに追加する必要があります。 単純に GeneralCategories のメンバをアイテムに追加することはできません。 図 4 のコードは、実行時に失敗します。失敗の原因は、ストアでは Categories のメンバが 1 つのアイテムで所有するネストされた要素であり、アイテム間で共有できないためです。 ネストされた要素には ItemKey プロパティがあり、それぞれの要素に一意の値が設定されています。 ただし、図 4 では、2 つのアイテムに対して、同じ ItemKey が設定されている、ネストされた要素を追加しています。 図 5 のソリューションは単純です。新しい CategoryRef オブジェクトを Categories プロパティに追加し、GeneralCategories クラスの値で初期化しています。 CategoryRef オブジェクトが新しく作成されると、一意の ItemKey が与えられます。
アイテムにカテゴリがあることがわかっている場合、FindByAllCategories、FindByAnyCategory、FindByCategory のいずれかを使用して、指定したすべてのカテゴリを持つアイテム、指定したカテゴリのうち任意の 1 つを持つアイテム、指定した 1 つのカテゴリを持つアイテムを検索できます。
通知機能
"WinFS" を使用する際は、アクセスするアイテムが実際にはデータ ソースのアイテムであることをよく忘れがちになります。 "WinFS" 通知機能はこの点を明らかにします。 名前からわかるように、"WinFS" 通知機能とはアイテムが変更されたときにコードに通知するメカニズムです。 通知のサブスクライブとその処理には、.NET イベント モデルが使用されます。 サブスクリプションの有効期間は、アプリケーション インスタンスが終了するまで、またはアプリケーションがサブスクリプションを解除するまでです。 特定のアイテムを監視するために ItemWatcher オブジェクトを作成できます。このオブジェクトには ItemChanged というイベントがあります。
public event ItemChangedEventHandler ItemChanged;
このデリゲートには、ItemChangedEventArgs パラメータがあります。 ItemChangedEventArgs.Details は、アイテムで発生した変更の種類を示す ItemChangedDetail オブジェクトのコレクションです。 つまり、あるアプリケーションからストアのアイテムにアクセスし、そのアイテムの ItemChanged ハンドラを追加できます。 その後、別のアプリケーションがアイテムを変更すると、最初のアプリケーションにイベントが発生します。
待ち受け側のアプリケーションは ItemWatcher.ItemChanged イベントにデリゲートを追加するだけで、アイテムが変更されるごとに通知が行われます。 この変更は、同じプロセスの中のコード、別のプロセスのコード、別のコンピュータのコードのいずれかによるものです。 一方のコンピュータから変更が行われると、同期によってもう一方のコンピュータにも変更が反映されます。
同期
繰り返しになりますが、"WinFS" はデータ ストレージ サービスなので、別のコンピュータのストアへのレプリケーションをサポートすることは自然なことだと言えます。"WinFS" ではこの機能を同期と呼びます。 同期を実装するには、"WinFS" でまず変更されたデータを判断し、レプリケートが必要なデータを判断する必要があります。 "WinFS" で追跡対象となるアイテムのスキーマの最小単位は要素です。 アイテムの要素が 1 つ変更されると、そのアイテムは変更されたと認識されます。 アイテムは "WinFS" における一貫性の最小単位であり、別のコンピュータにレプリケートできるデータの最小単位になります。つまり、アイテムは丸ごとレプリケートされるか、まったくレプリケートされないかのいずれかです。
ユーザーは、同期に加わるコンピュータを特定する必要があります。 これを行うには、すべてのコンピュータから使用するコミュニティ フォルダを作成し、ローカル コンピュータのアイテムの実際のフォルダと関連付けます。 同期は WinFS API から開始するか、スケジュールが設定されたタスクとして起動できます。 いずれの場合も、操作を開始したアプリケーションから "WinFS" に同期プロファイルが渡されます。 このプロファイルは、同期するフォルダに関する情報、方向 (送信のみ、受信のみ、または送受信)、および同期するアイテムについての情報です。 さらに、競合の処理方法についての情報も含まれています。 競合回避モジュールというコードにより自動処理が可能な競合のポリシーによって、レプリケーションの拒否と同様に簡単にアクションを呼び出すことも、ユーザーの操作を要求することもできます。
"WinFS" と Win32
"WinFS" は魅力的で多機能なシステムです。"Longhorn" 対応の新しいアプリケーションを構築する開発者は、その機能を十分に活用すべきなのですが、当然のことながら、"Longhorn" に移行するアプリケーションのほとんどで、レガシ Win32 コードが使用されることになるので、両者の連携をどのように取るかという問題が発生します。
まず説明が必要なのは、"WinFS" は NTFS に取って代わるものではなく、"Longhorn" を実行するコンピュータでも NTFS ベースのドライブが使用されることです。 現時点で "WinFS" は Documents and Settings フォルダのフォルダにのみ適用されています。 それ以外のフォルダは、現在もすべて NTFS で制御されています。 特に、%systemroot% フォルダと Program Files フォルダは NTFS なので、アプリケーション実行可能ファイルは "WinFS" ストアには格納されないことになります。
もちろん、Win32 ベースのアプリケーションも、Documents and Settings のフォルダ内のファイルの読み取りと書き込みを行うことは可能です。"Longhorn" には、"WinFS" ストアのアイテムを利用するために、Win32 ファイル API が実装されています。 Win32 から移行した Documents and Settings のすべてのアイテムはファイルと関連付けられており、したがって1つのアイテムが "WinFS" アイテムとしての側面と、ファイルとしての側面を持つことになります。既知のファイルの種類に対しては、ファイルを読み取り、メタデータを "WinFS" のプロパティとしてストアに抽出する機能があるメタデータ ハンドラが、種類ごとに関連付けられています。 たとえば、Microsoft Word に関連付けられているメタデータ ハンドラは、Word のファイルを読み込み、設定されている SummaryInformation OLE プロパティを読み取り、読み取った情報を使用してストアの "WinFS" の Document 型を初期化します。
ファイルと関連付けられているアイテムがあり、ストアには対応するメタデータ プロパティが保管されているという二重性によって、Win32 で引き続き Documents and Settings のアイテムにアクセスすることも、"WinFS" でクエリの構成要素としてプロパティを使用することも可能になっています。"WinFS" では、これらのプロパティが読み取り専用として処理されます。 Win32 ベースのアプリケーションでファイルが変更されると、メタデータ ハンドラによってストアが新しいプロパティ値で更新されます。 その本質的な意味とは、"WinFS" を実行しているコンピュータのマイ ドキュメント フォルダに Word 文書をコピーすると、ファイルに関する情報が "WinFS" ストアに格納されて、ファイルのプロパティを基に検索を実行できるようになるということです。 ただし、ファイルは Win32 からも引き続きアクセスできるので、Word での読み込みおよび編集は可能です。 Win32 でファイルを変更すると、更新されたプロパティが "WinFS" に読み取られ、ストアに書き込まれます。 つまり、Word 文書を 1 ページ追加してファイルを保存すると、Document.DocPageCount プロパティが更新され、このプロパティを基にした検索が予期したとおりに機能します。
まとめ
"Longhorn" の新しいファイル ストレージ システム "WinFS" は、"Longhorn" のすべてのアプリケーションの基本的な構成要素です。この資料では、"WinFS" で実現できることのほんの一部を紹介しました。 "WinFS" には、プロパティを基に分類および検索できるアイテムを持続的に保有するために必要な機能が、すべて用意されています。 "WinFS" の機能を活用して、次世代の Windows ベース アプリケーションを作成してください。
