I'm probably totally wrong on this, I'm no architect, but I feel something odd in the concept of multiple has_many relationships to the same class. Something like a classroom having many chairs as well as many chairs.
If I wanted to split them, there must be a difference..? And if I would need, say, many benches as well as many chairs, why not subclass a SeatingContraption class into a Chair class and Bench class? I'd still have access to the base class as well...
I'd really like to see some simple example of where I would need to - just to get my head around this, because I'm kind of stuck in my own weird logic I guess :-(
Thanks for the help guys. I got it working using martimiz's code. I had a look at the docs after Willr pointed me in the right direction but I still didn't see how it worked exactly. Cheers for clearing it up martimiz!
@Sticks: glad to have been of help and same apologies here!
@swaiba: I see your point. For the sake of argument - if you were to approach it from the Location point of view, define a Seller and Redeemer that would do the actual work of selling and redeeming, both have_one Location. Vouchers will have their own set of sellers and redeemers - that may or may not share a Location. That feels sort of right to me, but again, I'm far from being an expert
But in terms of overhead and CMS management... I get it :-( So maybe dot notation is supposed to be a 'naming' shortcut for this kind of structure? Then indeed it should work for many_many as well.
Obviously I'd like to continue this discussion, but I fear this probably is not the right place :-)