ruby-on-rails - 遅延ジョブ：保存されていないActiveRecordオブジェクトを他のものに適用します

Question

Thing保存されていないActiveRecordオブジェクトを保存されたオブジェクトの配列に適用しようとしていますPerson。

person has_many :things

ただし、Delayed Jobは、保存されていないActiveRecordモデルで動作することを目的としたものではありません。彼らが私に言ったので私は知っています：

DJは、保存されていないActiveRecordモデルで動作することを意図していません。

https://github.com/collectiveidea/delayed_job/wiki/Common-problems#wiki-DJ_doesnt_deserialize_an_unsaved_ActiveRecord_model

...エラーを回避できません：

{ActiveRecord::RecordNotFound, class: Thing , primary key:

私はそれを回避するためにいくつかの戦略を蹴っています：

1）ここからself.yaml_newをオーバーライドします。ひどい考えのように聞こえます。

2）オーバーライドThing.findして、見つからないオブジェクトから回復し、保存されていないオブジェクトをハイドレイトします。それは＃1よりもさらに悪い考えです

3）Thing最初にデータベースに保存します。ジョブをクリーンアップする必要がある孤児Thingがデータベースに存在するため（Thingsは実際にはアタッチされていないと存在しませんPerson）、ジョブの呼び出し元はThing最初のものを保存することを知っている必要があります。の検証をオーバーライドしますPerson。最悪。

4）Thing.to_open_structARの詳細をDJシリアル化のためにOpenStructにダンプするメソッドを作成します。ちょっと散らかっています。そのメソッドを移行と同期させる必要があります。理想的ではありませんが、これまでで最高です。

何か案は？未保存のDJをシリアル化するつもりはありませんThing。ただ、クリーンなソリューションが必要です。

Answer 1

1 つのアイデアは、UnsavedThing と呼ばれる新しいテーブル/モデルを作成することです。これは、関連付けはありませんが、基本的に Thing と同じです。

DJ は UnsavedThing を見つけ、それを使用して Thing.new を呼び出し、処理を行い、Thing.save を呼び出し、次に UnsavedThing.destroy を呼び出します。

それほどエレガントではありませんが、代替手段も優れていません。

最初にモノを保存できない理由は何ですか? クラスがどのように相互作用するか、および Thing をいつ保存できるかの基準についてより多くのコンテキストを提供できれば、より良い解決策があるかもしれません。