問題タブ [apache-cayenne]

オブジェクトのコレクションを削除しようとしていますが、どういうわけかまだ残っています。

commitChanges が実行された後、コレクション内の唯一の割り当てには次の値が含まれます。

deleteObject() の後、状態は DELETED になると思いました。commitChanges() の後は、コレクションに残してはいけません。これによると：http://cayenne.apache.org/docs/3.0/persistent-object-lifecycle.html。

私は何が欠けていますか？

編集: コードを変更して別のデータ オブジェクトを削除し、それによって変更が割り当てに反映されました。

例: ■ クラス A のオブジェクト a が、オブジェクト b、c、および d と関連しています。
私が行った場合：

じゃあ後で：

a から b および c への関係は無効になります (DataRowUtils の 115 行目を参照)。

Cayenne 3.0.2 を使用していますが、動作はバージョン 3.1 と 3.2M1 で同じようです。

この問題を回避する方法はありますか?

私の考えは、この関数でクラス A の CayenneDataObject をオーバーライドすることです。

それは悪い考えですか？うまくいくようです。
ロードしたら、データベースから b と c をまったく更新したくありません。
ありがとう

Apache Cayenneを使用して、属性値のコレクションがあるときに DB への反復呼び出しを回避する方法を見つけようとしています。

タイプStringPersonの属性を持つ永続オブジェクトがあるとします。の名前を含むリストがある場合、リストを反復処理して順番に取得するのではなく、単一のDB 呼び出しを許可する式を生成したいと考えています。namePersonPerson

これは実際には存在しませんが、次のようなものが欲しいです：

Cayenne インターフェイスを介して永続オブジェクトを保存しようとしています:

このバリアントでは、対応するテーブル フィールドは、次のような奇妙な文字列を保存した後に保存されます。

({1.0,2.0}) のようなものではありません。Double[] の代わりに sql 配列型を使用すると、シリアル化できない例外をスローしても保存されません。

ステータスが「クローズ」のカイエンのトラッカーで、多くの JPA 関連の問題を発見しました。しかし、ソースにはJPA関連のものは何もありません。
cayenne での JPA 互換性の状況に興味があります。
完了したこと、進行中のこと、リリースされていないコードを使用してヒットできる問題。そして、その作品のソースはどこにあるのか、おそらくブランチ名です。
私が欲しいのはJPAアノテーションです。おそらく、JPA アノテーションからのいくつかのカイエンの xml ジェネレーター、またはアノテーション付きクラスを処理できるある種の JPA アノテーション対応 DataMapProvider です。または、xml から Java ソースへの後方ジェネレーターかもしれません。

performQuery()2 つの引数を取り、次のようなApache Cayenne で実行するカスタム SQLite 関数を作成しようとしています。

を使用してみorg.sqlite.Function.create()ましたが、接続が Cayenne によってラップされているため失敗しました。

セッションに ObjectContext を保存しています。現在、同じセッションに対して複数の ajax リクエストがあり、すべて ObjectContext のデータを変更しています。これらのリクエストがスレッドセーフであることを確認するにはどうすればよいですか?

次のドキュメントでは、コンテキストのネストを使用することを提案しています。誰かがこれがどのように機能するかの具体例を教えてもらえますか? または、ネストされたコンテキストがスレッドセーフなリクエストを許可する方法の説明さえあります。または、これらのケースでのベスト プラクティスのドキュメントへのリンクです。ありがとう！

https://cayenne.apache.org/docs/3.1/cayenne-guide/persistent-objects-objectcontext.html

ネスティングは、分離されたオブジェクト編集領域 (子コンテキスト) を作成するのに役立ちます。これらはすべて、中間のメモリ内ストア (親コンテキスト) にコミットするか、親に既に記録されている変更に影響を与えずにロールバックする必要があります。カスケード GUI ダイアログ、または同じセッションに送られる並列 AJAX リクエストを考えてみてください。

編集:ドキュメントで次の段落が見つかりました。

データベースからオブジェクトをフェッチするためだけに使用され、オブジェクトがアプリケーションによって変更されることのないコンテキストは、複数のユーザー (および複数のスレッド) 間で共有できます。変更されたオブジェクトを格納するコンテキストには、1 人のユーザーのみがアクセスする必要があります (たとえば、Web アプリケーションのユーザーは、同じ HttpSession 内の複数の Web 要求間でコンテキスト インスタンスを再利用し、コミットまたは変更を決定するまで、オブジェクトへのコミットされていない変更を要求から要求へと運ぶ可能性があります)。それらをロールバックします)。1 人のユーザーであっても、複数の ObjectContext を使用することは理にかなっている場合があります (たとえば、オブジェクトを個別に変更およびコミットするブラウザーからの同時要求を許可する要求スコープのコンテキスト)。