はじめに
多くの時間が経過し、ライブラリが変更されたため、説明を続けていくつかのポイントを強調することにしました。 ユーザーの建設的な批判に感謝します。これはユーザビリティの向上に役立ったと思います。
最初に注意したいのは、ルートオブジェクトを操作するためのメソッドのグループがメインファサードクラスXmlDataStoreから削除されたことです。 現在、オブジェクトはルートと残りの部分に分離されていません。
インターフェースIXmlDataStoreIdentifiable
最初のバージョンについて説明するとき、データモデル開発者はgetId（）およびsetId（）メソッドを何らかの目的で使用でき、java.lang.Stringタイプでは必ずしも機能しないことが正しく指摘されていたため、メソッドの名前はgetDataStoreIdに変更されました（）およびsetDataStoreId（）。 インターフェースは次のようになります。
public interface IXmlDataStoreIdentifiable { String getDataStoreId(); void setDataStoreId(String dataStoreId); }
このインターフェイスを実装する抽象クラスも追加されました。
public abstract class AbstractXmlDataStoreIdentifiable implements IXmlDataStoreIdentifiable { private String dataStoreId; @Override public String getDataStoreId() { return dataStoreId; } @Override public void setDataStoreId(final String dataStoreId) { this.dataStoreId = dataStoreId; } }
インターフェイスと抽象クラスの両方から継承できます。
ファイル形式
ライブラリには、オブジェクトのファイル形式を他のものに変更する機能が導入されました。 これは、ライターとリーダーを提供するファクトリを使用して行われます。
public interface IXmlDataStoreIOFactory { IXmlDataStoreObjectsReader newInstanceReader( Map<Class<? extends IXmlDataStoreIdentifiable>, XmlDataStorePolicy> policies); IXmlDataStoreObjectsWriter newInstanceWriter( Map<Class<? extends IXmlDataStoreIdentifiable>, XmlDataStorePolicy> policies); }
各メソッドのパラメーターがストレージポリシーのマップであることが明確にわかるため、ライターとリーダーの実装はオブジェクトのストレージタイプを決定し、個々のオブジェクトを単純なリンクとして保存できます。 インターフェイスは次のとおりです。
public interface IXmlDataStoreObjectsWriter { void writeReferences(Writer writer, Collection<IXmlDataStoreIdentifiable> references) throws XmlDataStoreIOException; void writeObjects(Writer writer, Collection<IXmlDataStoreIdentifiable> objects) throws XmlDataStoreIOException; }
ライタークラスは2つのメソッドを実装する必要があります。
1）リンクをシリアル化するためのメソッドwriteReferences（）;
2）writeObjects（）オブジェクトをシリアル化するためのメソッド。
さらに、これらのメソッドの実行中にエラーが発生した場合、XmlDataStoreIOException型の例外をスローする必要があります。
public interface IXmlDataStoreObjectsReader { Collection<IXmlDataStoreIdentifiable> readReferences(Reader reader) throws XmlDataStoreIOException; Collection<IXmlDataStoreIdentifiable> readObjects(Reader reader) throws XmlDataStoreIOException; }
リーダーインターフェイスは対称的であり、リンクとオブジェクトを逆シリアル化するためのメソッドを定義します。
異なるフィールドによるオブジェクトの選択
最初のバージョンはさまざまなフィールドでオブジェクトを選択する機能を提供していなかったため、この機能はIXmlDataStorePredicateインターフェイスを介して後のバージョンで実装されました。
public interface IXmlDataStorePredicate<T extends IXmlDataStoreIdentifiable> { boolean passed(final T object); }
オブジェクトを結果セットに含める必要がある場合、passed（）メソッドはtrueを返す必要があります。 XmlDataStoreクラスでは、次のメソッドが実装されています。
public <T extends IXmlDataStoreIdentifiable> Map<String, T> loadObjects( final Class<T> cl, final IXmlDataStorePredicate<T> predicate) throws XmlDataStoreReadException
フラグメンテーション
前の記事で既に述べたように、「断片化とは、1つのファイル（ClassObjectsFileポリシー）を限られた数のオブジェクトを含むフラグメントに分割することを意味します。この場合のインデックスには、オブジェクトが保存されるフラグメントファイルを示すリンクが含まれます。」 フラグメント化を使用するかどうかは、オブジェクトの数でフラグメントのサイズをコンストラクターで指定するだけで、リポジトリを初期化するときに設定されます。
断片化すると、多数のオブジェクトを設定するのが望ましくないことに注意してください.1つのフラグメント内で1つのトランザクションのみが変更を実行できるため、残りは、変更を開始したトランザクションが受け入れられるかロールバックされるまで拒否されます。
私はこの瞬間が本当に好きではないので、次の実装では、おそらくそれが作り直されるでしょう。
トリガー
ライブラリの最新バージョンでは、オブジェクトが変更、追加、または削除されたトランザクションの一部として実行されるトリガーが追加されます。 トリガーは、変更されたオブジェクトのトランザクションデータが受信された後、データがディスクに書き込まれるまで呼び出されます。 したがって、受信したオブジェクトの追加処理はトリガー内で許可され、他のクラスのオブジェクト（つまり、別のリソースオブジェクトに格納されているオブジェクト）の変更は、既にディスクにフラッシュできるため非常に望ましくありません。 トリガーインターフェイスは次のとおりです。
public interface IXmlDataStoreTrigger<T extends IXmlDataStoreIdentifiable> { XmlDataStoreTriggerType getType(); Class<T> getClazz(); void perform(T object); }
getType（）メソッドは、トリガーを呼び出す操作のタイプを返す必要があります（オブジェクトの追加、変更、削除）。 getClazz（）メソッドは、トリガーが構成されるオブジェクトのクラスを決定します。 そして、受信したオブジェクトに対していくつかの操作を実行するperform（T object）メソッド。 受信したオブジェクトの変更が許可されています。
あとがき
xdstore-1.5の最新リリースは、すでに使用できるリポジトリの安定したデバッグバージョンです。 インターフェイスはもう変更されません。 以下の変更は、ユーザーから隠された内部最適化のみに関係します。
したがって、使用する必要がある場合、および/または使用する場合は、 xdstore-1.5を歓迎します。
作成者：Beschastny Evgeny