But that's only one way. What if I have two columns, called "sender"
and "receiver" and it doesn't really matter who is the sender and who
is the receiver as long as that "grouping" doesn't exist previously.
For example, assume I have this already in the database:
Sender = 1, Receiver = 2
Then, the following should occur:
Sender = 1, Receiver = 3 # => PASS
Sender = 1, Receiver = 2 # => FAIL
Sender = 2, Receiver = 1 # => FAIL
Sender = 3, Receiver = 1 # => FAIL (if the first one that passed
already happened)
But that doesn't quite do it because they aren't tied together. I can
custom-validate this but I was wondering if this pattern has already
been accounted for somehow.
I've headed down path #2, but I thought of posting here just in case
there already existed a custom validation. Maybe this isn't a very
common thing. Seems to be that usually it's explicit in the direction
(i.e. "husband => wife" relationship or "employer" => "employee" or
something like that).
Your thought would work, except that it's very much like 'friendship'
in that it's immaterial who requested the 'friendship'. And that's the
crux of it. Since Person 1 or Person 2 could be the sender/requester,
it has to check both ways.
Then again, I just had a thought. Perhaps given two people, the lower
ID is always set as the sender and the other as the receiver. Hmmm...
then, the order would always be known.
If Person 2 requests friendship with Person 1, the friendship object
is saved with sender=>1, receiver=>2
Then, if later Person 1 requests friendship with Person 2, it's saved
as sender=>1, receiver=>2 and it would fail validation.
Interesting... I need to noodle on that a bit more and see if that
would work thoroughly.
The downside to this ID reordering is that I'd lose the data about who
did the request.
For the 'friendship', it doesn't matter. I.e. Person 1 is connected to
Person 2 is exactly the same functionally as Person 2 is connected to
Person 1 (in my app, that is). But there may be value in knowing which
person started the process (i.e. the "sender").