問題タブ [jcr]

jackrabbit-users リストでこの質問をしましたが、答えが得られませんでした。

JCR-SQL2 は SELECT DISTINCT (または同様の、AFAIK) を提供しません。JCR 1.0 の SQL や XPATH も同様です...人々はこれをどのように回避していますか?. 重複行を削除する最良の方法は何ですか?

誰かが結果を反復処理してセットに入れていると読みました。私の場合、膨大な数の結果が得られる可能性があるため、そのアプローチはコストがかかりすぎる可能性があります。

ここに誰か提案がありますか？

リポジトリ内のコンテンツを管理するためのフレームワークとしてのみ Alfresco を使用できるかどうかを知りたいです。上のすべての派手なレイヤーなし。

私はいくつかの maven alfresco アーキタイプを試しましたが、それらは主に拡張機能と alfresco 共有を作成することを目的としています - 私はそれをあまり理解していません。

とにかく、おそらく alfresco は典型的なオープンソース プロジェクトではないため、Maven のサポートは非​​常に混沌としているようです。そして、たとえば、必要なことを行う方法を説明する開発者ガイドが見つかりませんでした:

含む ：

JCR フレームワークの用語で使用します。誰か助けてくれませんか？

プロジェクトに使用する永続性マネージャーのタイプを決定しようとしています。私はpersistenceManagersに関するこのwikiエントリを読みました。

まず第一に、JCR-2802（すべての非バンドルPMは非推奨）のため、

そして、それらすべてのInMem、Object、XmlPersistenceManagersは非推奨になりました。（InMemPMが非推奨になっている間もMemoryFileSystemはOKですか？）

これを見ると、BundleFsPersistenceManagerはLocalFileSystemを使用してファイルを永続化し（コンテンツがファイルに保存される方法を説明するwikiエントリはありますか？-nt：fileなどのさまざまなタイプのノードプロパティのように）、BundleDbPersistenceManagerはDbFileSystemを使用しますまったく同じファイルをDBMSに保存するには？そうしないと、Luceneのインデックス作成と全文検索ができません。

その理由は、システムのクラスタリングと分散性、および原子性です...そうでなければ、データベースの実装は冗長になりますよね？このように人々はより多くの選択肢を持っています。

私はこれを理解しようとしています.Liferayのフォーラムでこの質問をしていました-最後のエントリ.

そして、私が思いつくことができるのは、FileEntry のExpandoを作成することだけですが、これは非常に複雑に思えます。それが理にかなっているのかどうかは誰にもわかりません。休止状態を介して適切にクエリを実行できなかったため、expando 機能は好きではありません。

そのLiferayフォーラムでの私の質問に対する答えを知っている人はいますか?

問題はそれです、

ファイルに関する追加情報/プロパティを保存することはできません。その結果、Liferay の JCRHook を使用する代わりに、JackRabbit を直接使用する必要があります。しかし、ドキュメント ライブラリがもたらす利点をすべて失うことになります。

JackRabbit に簡単にアクセスするためのある種の抽象化を開発者に提供するライブラリがあるかどうか疑問に思っていました。

jackRabbit を利用し、そのような抽象化を行う CMS がいくつかあるという事実を認識しています。

このすべてをカバーするもの：

例 ：

このレイヤーを自分で実装するつもりですが、実装されている「ホイールを実装」しないことを確認したかったのです。

私はこれについて疑問に思っていました。私は ECM プロジェクトで jackrabbit を採用することを計画していますが、OCMが死にかけているように見えますが、プロジェクトの残りの部分とは別のフォークです。Maven リポジトリには古いjackrabbit-ocm-nodemanagement jackrabbit-ocmバージョンがあります。それ以外の場合は、参照ドキュメントで参照されている zip アーカイブを介してプロジェクト自体をダウンロードできます。

org.springmodules.jcr は、公式の Spring ソース ベースにはなりませんでした。それは放棄されました。ジャックラビット OCM の素晴らしい接着剤であり、プロジェクトは素晴らしいように見えますが. なぜそんな重要な仕様を残すことにしたのか、私にはまったく理解できません!?!?!?

現在、ある種の保護としてここに存在しています。また、私が推測する同じものと思われるjcr スプリング エクステンションもあります。Jira セクションがありますが、すべてが放棄されているように見えます。厄介なバグで問題が発生した場合、サポートは受けられません。

私より明るい情報があれば教えてください。

既存のJackRabbitリポジトリを使用するようにliferayをセットアップできるかどうか疑問に思っていますcom.liferay.documentlibrary.util.JCRHook

これらすべてのプロパティをリポジトリに一致するように設定すると、機能しますか?

リポジトリは、主nt:file - nt:content with nt:resources に「jcr」と mixin プロパティを持つものです。私はそれらには興味がありません。Liferay のドキュメント ライブラリを介してリポジトリ内のファイルにアクセスできるようにする必要があるだけです。

CMIS 統合の使用は避けて、このようにしたいと思います。

ねえ、 3番目の選択肢に何か問題があります。ループはJcrServiceFactoryjcr。*で始まるプロパティを検索しているためです（他は渡されません）が、（Jackrabbit impl）の直後にRepositoryFactoryImpl「org.apache.jackrabbit」が検索されます渡されたプロパティのコレクションの.repository.home"...それは意味がありません。org.apache.jackrabbit.repository.homeが存在する場合でも、それはで始まらないため、次の場所に移動するコレクションにPREFIX_JCR_CONFIGは入れられません。jcrConfigRepositoryFactoryImpl.getRepository()

に条件Map<String, String> map = null;があるので意味がありますが、これは意味がありませんif (parameters == null)RepositoryFactoryImpl

これはinitメソッドで発生します

JcrServiceFactory.java

しかし、ここではパラメータMapは空{}であり、nullを返します。org.apache.jackrabbit.repository.homeであるRepositoryFactoryImpl.REPOSITORY_HOMEを検索しているためです

RepositoryFactoryImpl.java

純粋な FS 永続性と比較して、jackrabbit のオーバーヘッドがどれだけあるかを知っている人はいますか?

私はCMSプロジェクトに使用していますが、一時ファイル（残念ながらプロパティ/メタデータがあります）も保持する必要があります...そのためにjackrabbitも使用する必要があるかどうかわかりません。

これを回避するには、オーバーヘッドが十分に大きいと思います....少なくともファイルシステムのIO。

これらのファイルはレポ内の残りのファイルと同じですが、すぐに削除されることは確かです。

JAVA IO API を介してプロパティを持つファイルを永続化するレイヤーを作成する必要がありますか? jackrabbit を使用する必要がありますか、それとも database を使用する必要がありますか? もしそうなら、どうにかしてパフォーマンスのために設定できますか？

Jackrabbit で「通常の」テキスト コンテンツ (文字列、HTML コードなど) を整理する方法を考えていました。プレーン テキスト コンテンツ (ファイルなど) に推奨される構造はありますか?

各テキストコンテンツをバイナリとして保存する必要があります (ファイルの場合と同様) Node(nt:folder)--> Node(nt:file) --> Node(バイナリを保持する jcr:data プロパティを持つ jcr:content)

それとも Node(nt:folder)--> Node(nt:unstructured with a jcr:message property that has the string.

私の 3 番目のアイデアは、テキスト コンテンツ用に別の名前空間を作成することでした。文字列を保持する jcr:message プロパティを持つ :html) ...

最善の解決策は何だと思いますか? これについて議論することは素晴らしいことです。