3

ユーザーがいくつかのモデル(記事、ブログ投稿など)の下書きを作成できるようにしたい。現在のモデル(articleDraft、blogpostDraftなど)ごとにドラフトモデルを作成して、これを実装することを考えています。これを行うためのより良い方法はありますか?ドラフトをサポートする必要がある既存のモデルごとに新しいモデルを作成するのは面倒で、大変な作業です。

4

5 に答える 5

7

レコードがドラフトであるかどうかを識別するために、テーブルにフラグ(例:draftと呼ばれるint列)を含める方が良いと思います。

私が見ることができるように、別のテーブルなしでそのような列を持つことの利点:

  1. レコードをドラフトなしにするのは簡単です(フラグを変更するだけです)

  2. データを複製しません(ドラフトレコードと非ドラフトレコードで実際に同じになるため)

  3. コーディングは簡単で、複雑なログインはありません

  4. すべてのデータが1つの場所にあるため、エラーの余地が少なくなります

于 2012-12-29T20:57:24.713 に答える
3

私は、ActiveRecordデータのドラフト状態を作成するためのRubygemであるDraftsmanに取り組んできました。

Draftsmanのデフォルトのアプローチは、ポリモーフィックな関係を介して、ドラフトされたすべてのモデルのドラフトデータを単一のdraftsテーブルに格納することです。オブジェクトの状態をJSONとしてobject列に格納し、オプションで、列の変更を表すJSONデータを格納しobject_changesます。

article_draftsDraftsmanを使用すると、必要に応じて、モデル(たとえば、 )ごとに個別のドラフトモデルを作成できますblog_post_drafts。このアプローチはかなり面倒でエラーが発生しやすいことに同意します。

ドラフトデータを別々のモデルに分割する(またはsameera207の回答に従って、メインテーブルでブールフラグを使用する)ことの本当の利点は、大量のレコードを含む巨大なテーブルにdraftなってしまうことがないことです。draftsただし、アプリケーションに大量の使用がある場合にのみ、これが実際の問題になることをお勧めします。

つまり、私の最終的な推奨事項は、すべてのドラフトデータをメインモデル(blog)または単一のdraftsテーブルに保存し、アプリケーションをスケールアップする必要がある場合は必要に応じて分離することです。

于 2015-09-22T20:04:26.517 に答える
2

RubyToolboxのActiveRecordVersioningカテゴリを確認してください。現在のリーダーはPaperTrailです。

于 2012-12-29T20:58:32.920 に答える
0

ステートマシンのルートをたどります。モデルが特定の状態にある場合にのみ、各属性を検証できます。複数のチェックボックスよりもはるかに簡単で、各状態の変更に1つまたは複数のアクションを関連付けることができます。

于 2012-12-30T00:23:13.417 に答える
0

モデルにフラグがあると、いくつかの欠点があります。

  • データが有効でない限り、ドラフトとして保存することはできません。もちろん、Railsモデルでの検証はスキップできますが、データベースで定義されている「NOTNULL」列について考えてみてください。

  • 「実際の」レコードを見つけるには、フィルターを使用する必要があります(「WHEREdraft = FALSE」など)。これにより、クエリのパフォーマンスが低下する可能性があります。

別の方法として、私の宝石の製図をチェックしてください。さまざまなモデルのドラフトを別のテーブルに保存します。

于 2015-08-04T09:07:04.273 に答える