問題タブ [orphaned-objects]

SQLデータベースで孤立したローカルWindowsユーザーを修正する方法を知っている人はいますか？

データベースを別のマシンにバックアップおよび復元しようとしています。どちらのマシンもドメインに属していません。異なるワークグループに属しています。何人かのWindowsユーザーは、ソースマシンのデータベースへのアクセス許可を持っており、ターゲットマシンのユーザーの再接続を容易にするために、同じユーザー名（ただし異なるパスワード）のユーザーを設定しました。

残念ながら、これは機能しません。データベースユーザーは、 [ユーザー名]としてだけでなく、[ソースマシン名] \ [ユーザー名]としてもやや無用に復元され、ターゲットマシン上のアカウントのリンクを妨げます。それらのユーザーを正しいWindowsアカウントに再接続する方法を知っている人はいますか？私は通常のグーグルを実行しましたが、利用可能な情報は通常、孤立したローカルWindowsユーザーを接続するためのものではなく、孤立したSQLユーザーを接続するためのものです。

orphanRemoval=true オプションについて多くの議論がありましたが、まだ孤児が残っていますが、私の問題に対する正しい答えが見つからないようです。

UniqueProperty クラスの List に OneToMany 関係を持つ Connector クラスがあります。

UniqueProperty には次の定義があります。

PostgreSQL DB を使用しています。新しいコネクタを作成して UniqueProperty (name, valueA) を追加すると、connector_uniqueproperty テーブルに 1 行、uniqueproperty テーブルに 1 行が作成されます。以前と同じ ID (新しい休止状態セッション) で新しい Connector インスタンスを作成し、今回は一意のプロパティを追加しない場合、session.saveOrUpdate(connector) 呼び出しは関連する行を connector_uniqueproperty から削除しますが、関連する行はそのままにしますuniqueproperty テーブル (現在は孤立しています)。

なぜこれが起こるのかについて何か提案はありますか?

JPA 2.0、Hibernate 4.1.0.Final、Spring 3.1.1.RELEASE、および Java 1.6 を使用しています。このエンティティは、別のエンティティと 1 対多の関係にあります …</p>

ただし、別の ClassroomUser オブジェクトのセットでエンティティを更新すると

エンティティを保存すると、以前のすべての ClassroomUser オブジェクトが残ります。データベースからすべての孤立したレコードを削除しながらエンティティを更新する適切な/最短の方法は何ですか?

ありがとう - デイブ

関数を呼び出して異なるストーリーボード間を移動するドロップダウン メニューを iOS アプリに実装しました。そのメニューの各要素は、別のストーリーボード名で AppDelegate クラスの次の関数を呼び出します。

問題は、呼び出される関数が一貫性なくアプリをクラッシュさせることです。一部の画面では機能し、他の画面では機能しません。さらに悪いことに、通常はクラッシュする画面でも機能することがあります。

コンソールにダンプされる 2 つのエラー メッセージがあり、それらは (読みやすくするために改行を追加しました)。

と

私を本当に混乱させるのは、「内部エラー....これは決して起こらないはずです」という最後の行です。

他の誰かがこのエラーに遭遇したかどうか、そして彼らがどのように対処したかが気になります。

• これは、変数 currentView の初期化の問題ですか、それとも AppDelegate のウィンドウ変数と関係があるのでしょうか?

• これは本当にストーリーボードの制約の問題ですか? その場合、1 つの画面に配置できる/配置する必要がある制約の数に制限はありますか?

編集：

エラーは、特定のストーリーボードから離れたときにのみ発生したことがわかりました。画面上の制約がエラーをスローしていました。そのため、changeController にいくつかのコードを追加しました。プログラムによってすべてのサブビューから制約を削除し、スーパービューからすべてのサブビューを削除します。

問題のある UIViewController の制約がクリアされ、再作成されたときに、問題は最終的に解決されました。

ご協力とご提案をありがとうございます。

これがバグかどうかわからないので、アドバイスを求めています...

(xcode 5.1.1 上の iOS 7.1.2)

私のアプリは、多くの大きなデータ イメージをコアデータに保存します。バイナリ イメージの属性は、エンティティで「外部ストレージを許可する」に設定されているため、アプリの _EXTERNAL_DATA サブフォルダーにファイル (guid) が表示されます。

このアプリの存続期間中、ファイルは定期的に変更されるため、既存の画像を上書きしてコンテキストを保存します。

問題は、新しいイメージ ファイル (GUID) の孤立したコピーが表示されるのに、古いイメージ ファイルが削除されないことです。

これは次のように再現できます...

コアデータを利用する「テスト」ボタンを備えたユーティリティ アプリを作成し、単純なエンティティを作成します...

viewDidLoad に最初のエンティティを作成し、それへの参照を保存します....

次に、ビューのボタンのアクション ハンドラーで、画像を変更するだけです...

-(IBAction)onTestImageButton:(id)sender { int randNum = rand() % 4 + 1;

ここでは、それぞれわずかに異なるサイズの 4 つの大きな jpg の平面があります。(サイズが同じであれば問題ありません)

アプリを実行し、「テスト」ボタンを数回押します。まもなく、ファイルのいくつかのバージョンが _EXTERNAL_DATA に表示されます

バージョンは 1 つしかないと思います。画像は孤立し、親エンティティがカスケード削除ルールを介してこれを削除すると、貴重なスペースを占有するファイルが残されます!

これはバグですか、それとも何か間違っていますか?

ありがとう

重要なお知らせ :この投稿を読んでいる場合は、詳細な議論のためにこの投稿も検討することを検討してください。

親の子が別の親に移行される可能性があるのは、非常に一般的な慣行/状況/要件です。このような関係の逆側に をorphanRemoval設定するとどうなりますか?true

例として、次のような単純な 1 対多の関係を考えてみましょう。

裏側（部門）：

所有側（従業員）：

次のような操作/アクションをマージしながら (departmentはクライアントから提供された切り離されたエンティティです)、

_{もちろん、従業員の追加と削除は、関連付けられたエンティティの防御リンク (関係) 管理メソッドを使用して行う/処理する方がよい場合があります。}

部門インスタンスは、クライアントによって提供されます。切り離された存在です。問題のクライアントによって実行される管理アクションに応じて、同じ部門または異なる部門になる可能性があります。その結果、クライアントによって提供された部門インスタンスが現在の によって保持されているものと異なる場合、追加する前に、それに関連付けられている逆側の現在の古いEmployee部門によって保持されている従業員 ( ) のリストから最初に削除する必要があります。それは、新しく提供された従業員のリストに追加されます。employeeListEmployeedepartment

推測として、従業員の部門によって現在参照されている従業員のリストからインスタンスEmployeeを削除しているときに、データベースから行が誤って削除される必要がありますEmployee-古い部門（この操作がトリガーされる前）、つまり、子を親から別の親の場合、子は別の親に養子縁組される前にネイティブの親から削除する必要があり、その子の行はデータベースから誤って削除されることになっています ( orphanRemoval = true)。

ただし、データベース テーブルの従業員行は、更新された列の値でそのまま残ります。ステートメント以外の DML ステートメントUPDATEは生成されません。

このように子を親から別の親に移行すると、データベース テーブルからそれらの子が誤って削除されることはありません。

現在、JPA 2.1 を持つ EclipseLink 2.6.0 を使用しています。

編集：

Employee逆側のリストからエンティティが削除されるだけの場合 (つまり、削除後にリストに追加されず、別の親に移行されずに削除されただけ)、対応する行も通常どおりデータベースから削除されます( orphanRemoval = true)ただし、Employeeエンティティ (子) がネイティブの親のリストから削除された後 (エンティティの移行)、エンティティ (子) が別の親のリストに追加されると、行は単純に更新されます。

プロバイダーは、親から別の親への子の移行を更新として検出するのに十分スマートであるように見えます。

この動作は、Hibernate (4.3.6 final) と EclipseLink (2.6.0) の両方で同じように見えますが、プロバイダー固有の動作 (移植性がない) である場合、信頼できません。JPA仕様では、この動作について何も見つかりません。

1 対多の関係 (国->) の非常に単純な例を取り上げます。

国（裏面）：

StateTable (所有側) :

StateTableアクティブなデータベース トランザクション (JTA またはリソース ローカル) 内で提供された (デタッチされた) エンティティを更新しようとするメソッド:

orphanRemovalに設定されていることに注意してくださいtrue。StateTableエンティティは、エンティティの関連付け ( ) を別のもの ( ) に変更することに関心のあるクライアント アプリケーションによって提供されます(CountryしたがってcountryId = 67、StateTableJPAcountryId = 68の逆側で、子エンティティをその親 (コレクション) から別の親 (コレクション) に移行します)。orphanRemoval=true逆に反対します）。

Hibernate プロバイダーはDELETEDML ステートメントを発行し、StateTableエンティティに対応する行を基になるデータベース テーブルから削除します。

orphanRemovalが に設定されているにもかかわらず、trueHibernate が通常のUPDATEDML ステートメントを発行orphanRemovalし、リレーションシップ リンクが移行される (単に削除されるのではなく) ため、 の効果が完全に中断されることを期待しています。

EclipseLink はまさにその仕事をします。指定されたシナリオでステートメントを発行します( set toUPDATEと同じ関係を持ちます)。orphanRemovaltrue

仕様に従って動作しているのはどれですか? この場合、逆側からUPDATE削除する以外に、Hibernate にステートメントを発行させることは可能ですか?orphanRemoval

_{これは、双方向の関係を両側でより一貫性のあるものにするための試みにすぎません。}

_{add()上記のスニペットで使用されている防御リンク管理メソッドremove()は、必要に応じて、Countryエンティティで次のように定義されます。}

アップデート ：

UPDATE指定されたコードが次のように変更されている場合、Hibernate は予期される DML ステートメントのみを発行できます。

新しいバージョンのコードで次の 2 行を確認します。

最後の行が存在しないか、またはEntityManager#getReference()に置き換えられているEntityManager#find()場合、DELETEDML ステートメントが予期せず発行されます。

それで、ここで何が起こっているのですか？特に携帯性を重視しています。この種の基本機能をさまざまな JPA プロバイダーに移植しないと、ORM フレームワークの使用が著しく損なわれます。

_{と の基本的な違いを理解していEntityManager#getReference()ますEntityManager#find()。}

エンティティのコレクション「AnnualReportStaffing」を受け入れるエンティティ「AnnualReport」があります。年次報告書には 4 つの異なる人員配置セクションがあるため、これらのコレクションのうちの 4 つ (ArrayCollection) があります。従来の 1 対多の関係を使用できないため、ここで説明されているように、Join Table で One-To-Many を使用する必要があります。

たとえば、Staffing コレクションの 1 つは、AnnualReport クラスで次のように定義されています。

AnnualReport を削除するときが来たら、Doctrine は結合テーブル内のレポートと Staffing の間の関係を削除しますが、関連する AnnualReportStaffing エンティティは削除しません。cascade={"remove"} を追加しようとしましたが、結合テーブルの関連付けが削除される前に Staffing エンティティを削除しようとしているため、外部キー違反が発生します。

孤立した Staffing エンティティを削除する最良の方法は何ですか? 明らかに orphanRemoval=true は答えではありません。