Use the scope
parameter on uniqueness_validation, something like:
validates :voter_id, uniqueness: { scope: :votefor_id }
scope parameters could be more than one:
validates :voter_id, uniqueness: { scope: [:votefor_id, :vote] }
Update: (App validation Vs Db constraint)
It really depends on the details but for the case in hand my personal opinion that db constraint is a bit overkill here because chances for a race condition (documented in rails uniqueness validation) to happen are low, since we need
two records with the exact same voter_id, votefor_id and vote to be submitted at the exact same time (we are talking about milliseconds), if i may assume something about the OP business logic that voter
would normally be a logged in user meaning duplicate entries should only come from him !!
conclusion:
I had quite a number of rails apps running in production using uniqueness_validation
just fine and only one time it failed me in a situation of a uniqueness check on a single column with many simultaneous entries (obviously i needed db constraint there).
If data integrity is critical you should for sure go with db constraint.
Or if you don't mind the overhead & specially if you could benefit from the new index on the (voter_id, votefor_id and vote) to increase search speed i would say go with db constraint.
otherwise i would say: keep it simple and stay with uniquess_valdation