2

現在の問題を解決するための最良の方法を今探しています。製品と写真の2つのモデルがあります。写真はhas_manyを介して製品に関連付けられます。ユーザーが新しい製品を作成するとき、実際の製品がデータベースに保存される前に、ネストされたフォーム（carrierwave、jquery）を使用して写真を追加することもできます。製品はまだ存在しないため、正しい関連付けで写真をデータベースに保存するための最良の方法を探しています。

いくつかの方法が頭に浮かびました。

1）ユーザーが「新製品」を押すとすぐに適切なIDで製品をデータベースに保存し、ユーザーが「キャンセル」を押した場合は後で再度削除します。このようにして、検証を少し混乱させ、代わりにクライアント側の検証を行う必要があります。製品の作成中にユーザーがブラウザウィンドウを閉じると、問題が発生する可能性があります。製品はデータベースに残ります。

2）データベースに保存し、奇妙なIDやis_tempフィールドなどを使用して、なんらかの方法でフラグを付けます。これにより、ユーザーがログインするたびにデータベースをクリーンアップできます。「Cance」はすぐに削除します。 （および関連するすべての写真）。

3）メモリに一時IDを作成し、まだ製品を保存しないでください。この一時IDに関連付けられていても写真を保存できます。ユーザーが最終的に保存を押すと、product_idを新しい実際の製品IDに変更します。

これまでのところ、Solution 2はそれを行うための最良かつ最もクリーンな方法のように見えます。これは、RyanBatesのGuestRecord Railscastに似ていますが、ここで何かが欠けている可能性があり、はるかに簡単な方法があります。他の解決策は高く評価されています。

どうもありがとう！

4

1 に答える 1

2

より堅牢なので、#1 を使用します。特に、API の場合ははるかに効果的です。

これにより、モデルを構築する習慣が身に付き、独自の方法でモデルを保存および変更できるようになります。たとえば、ユーザーが写真のない製品を本当に欲しがっている場合があります。

私の実際のアプリはまさにこの設定です。ユーザーが正しくアップロードされていない写真を使用して製品を作成しようとしても、製品は正しく保存され、正しく検証されます。

さらに、アプリには、製品を作成するための呼び出しと、その後に写真を追加するための別の呼び出しを含む API があります。関連するすべての写真とは無関係に製品を作成できることは、API クライアントにとって非常に便利です。

製品がデータベースに取り残されたままになるため、#2 は避けてください。さらに悪いことに、その製品は検証されていません。これは、すべてのレポート クエリで取り残されたレコードを強制的に除外しない限り、レポートなどのアプリの他の領域で問題を引き起こす傾向があります。

トランザクションでそれが必要な場合、および/またはこの場合に最速の速度が必要な場合にのみ、#3 を検討してください。最初にすべてをメモリ内で実行すると、トランザクションに必要なすべての要素が含まれていることが保証され、データベースへのアクセスが節約されます。

于 2013-01-07T15:38:17.240 に答える