問題タブ [validates-uniqueness-of]

(同じ種類の) 2 つのオブジェクト間の双方向リンクを保存することになっている単純なモデル "Match" があります。

私が抱えている問題は、発見した双方向の各 Match に対して、2 つのデータベース エントリを取得することです。例 1: obj1 -> obj2、2: obj2 -> obj1

validates_uniqueness_ofここでこれを回避するにはどうすればよいですか？私は試した

しかし、それはうまくいきませんでした。

ActiveRecord の一意性バリデーターには、値が nil または空白の場合に検証をスキップするオプションがあります。両方のパラメーターを true (デフォルトの動作) に設定しても、検証がヒットする前に、nil と空白で 1 つのレコードを作成できます。デフォルトの SQLite3 データベース sqlite3-ruby (1.2.5) を使用します。

明確にするために編集：validates_presence_ofモデルに追加すると、期待される結果が得られます。validates_uniqueness_ofのデフォルトの動作により、これが冗長になると思いました。

テストケース：

app/models/thing.rb の内容:

Rails コンソール:

最初の 2 つの作品が合格するのはなぜですか?

ありがとう

ユーザーごとに 1 日 1 回だけモデルの保存/更新を許可する必要がある Rails モデルがあります。ユーザーと日付で検索してエラーに追加するコールバックがありますが、これは見苦しく、レールに似ていません。私は典型的な created_at / updated_at 列を持っています (そして時間部分は重要です/それを維持する必要があります)。

だから私はどちらかができると思います：

1）作成日とそれによる範囲だけの別のモデル属性を作成します（bleh）

2) :scope 属性を使用しますが、どうにかして created_at の日付部分だけを取得します。

3) => Proc.new{ |o| でない限り検証します。既存のコールバックに一致するファインダー } (グロス)

http://ar.rubyonrails.org/classes/ActiveRecord/Validations/ClassMethods.html#M000086

これらの数が圧倒的に多いわけではありませんが、Ruby ではなく SQL で実行することをお勧めします (明らかなスケーラビリティの理由から)。

何かご意見は？より良い方法はありますか？

とLabellingsに属するものがEmailsありLabelsます。

各ラベルは、電子メールとラベルのペアに固有である必要があります。そのため、電子メールに「テスト」のラベルを付けることができるのは1回だけです。

私はこれをでやっていvalidates_uniqueness_of :label_id, :scope => :email_idます。これは期待どおりに機能します。

メールにラベルを付けるときに、一意のラベルを追加したいのですが、メールにすでにそのラベルが付けられている場合は何もしません。

次のようなものでアプリの検証機能を複製したくありません。

手動でチェックしたり例外を処理したりせずに、各ラベリングに一意のemail_id / label_idペアがあることを確認することは可能ですか？

Core Data エンティティのプロパティで更新された値を、コレクション内の他のエンティティのプロパティの値に対して検証する方法はありますか?

現時点では、いくつかのデフォルト値を持つエンティティを作成し、それを に追加してからarrangedObjects、ユーザーにさまざまなプロパティ値を変更してもらいます。ただし、特定のプロパティをチェックして、そのプロパティに同じ値を持つエンティティが配列内に他にないことを確認したいと思います。これを行う最善の方法は何ですか？

どうもありがとう、ダニー。

Rails 2.x では、検証を使用して、次のような一意の組み合わせ値があることを確認できます。

対応する移行では、次のようになります。

これにより、夫と妻の組み合わせがデータベース内で一意になるようになります。現在、Rails 3 では検証構文が変更され、scope 属性がなくなっているようです。次のようになります。

Rails 3で結合された検証をどのように達成できるか考えていますか? Rails 2.x のバリデーションは Rails 3 でも機能するので、最初の例を引き続き使用できますが、「古い」ように見えます。より良い方法はありますか?

Task のネストされた属性を受け入れる Project モデルがあります。

タスク モデルの一意性検証は、プロジェクトの更新中に問題を引き起こします。

プロジェクトの編集で、タスク T1 を削除してから、同じ名前の T1 で新しいタスクを追加すると、一意性の検証によりプロジェクトの保存が制限されます。

params ハッシュは次のようになります

タスクの検証は、古いタスクを破棄する前に行われます。したがって、検証は失敗します。タスクが破棄されたと見なされないように検証する方法はありますか?

validates_uniqueness_ofとは正反対の検証を行うことはできますか？つまり、ユーザー入力がデータベースに存在しない場合にエラーメッセージを表示したいと思います。

皆さんありがとう。:)

移行ファイルには次のものがあります

product_id が指定されている場合は一意であることを確認したいのですが、null も許可したいので、モデルに次のように記述します。

うまく機能しますが、移行ファイルにインデックスを追加する必要があります

product_id に 2 つの null 値が挿入されると、明らかに例外がスローされます。移行で単にインデックスを省略することもできますが、次に示すように、同じ product_id を持つ 2 つの PaymentAgreements を取得する可能性があります:同時実行性と整合性

私の質問は、この問題に対処するための最良/最も一般的な方法は何ですか