Specify and validate requirements on an ActiveRecord association

Looking for some guidance/support on what feels like might not be an
uncommon use-case.

`User.has_many accounts`
`User.has_many payment_methods`
`Account.belongs_to :user`
`Account.belongs_to :payment_method`
`PaymentMethod.has_many :accounts`

There are lots of `Accounts`. When I (a `User`) want to assign
accounts to a `PaymentMethod`, I really don't want to scope against
all of them, but rather only those that I own. While this can be done
at the controller level, it feels like a data-level constraint.

I will want a validation, to ensure I do not map `PaymentMethods` to
`Accounts` with different `Users`. But I will also want a way to
specify the scope of possible associations, effectively using the same
logic as the validation. Placing conditions on the association doesn't
restrict invalid associations, nor does it imply that.

A useful syntax might be:

`PaymentMethod.has_many :accounts, requirement: proc {self.user ==
target.user}, scope: true, validate: true`

Expressing `my_payment_method.accounts` would use `requirement` as a
condition. A reflection on the association
(`PaymentMethod.possible_accounts`) could return a relation that could
be used to scope out the possible valid associations from the target
(`Accounts`). The validate flag could generate a matching DRY
validation that ensures the same condition at the instance level.

Realizing that crossing realms of associations and validations might
not be the most desirable, but seem inherently required in order to
avoid repetition.

Does anyone have any insight on this?

Looking for some guidance/support on what feels like might not be an
uncommon use-case.

`User.has_many accounts`
`User.has_many payment_methods`
`Account.belongs_to :user`
`Account.belongs_to :payment_method`
`PaymentMethod.has_many :accounts`

There are lots of `Accounts`. When I (a `User`) want to assign
accounts to a `PaymentMethod`, I really don't want to scope against
all of them, but rather only those that I own. While this can be done
at the controller level, it feels like a data-level constraint.

I will want a validation, to ensure I do not map `PaymentMethods` to
`Accounts` with different `Users`. But I will also want a way to
specify the scope of possible associations, effectively using the same
logic as the validation. Placing conditions on the association doesn't
restrict invalid associations, nor does it imply that.

A useful syntax might be:

`PaymentMethod.has_many :accounts, requirement: proc {self.user ==
target.user}, scope: true, validate: true`

Expressing `my_payment_method.accounts` would use `requirement` as a
condition. A reflection on the association
(`PaymentMethod.possible_accounts`) could return a relation that could
be used to scope out the possible valid associations from the target
(`Accounts`). The validate flag could generate a matching DRY
validation that ensures the same condition at the instance level.

Realizing that crossing realms of associations and validations might
not be the most desirable, but seem inherently required in order to
avoid repetition.

Does anyone have any insight on this?

You could add a validation to account that checks that payment_method.user_id is the same as user_id.

Another approach would be to change your schema. Would this work?

user has_many payment_methods
user has_many accounts, :through => :payment_methods

Payment method is unchanged and for account you'd probably need has_one :through to get at the user

To me, the advantage of this method is that the case of an account having a payment_method from the wrong account becomes simply impossible to express.

Fred.

Thanks for replying. This is solvable with a combination of
validations and controller logic, but I'm considering a syntax that
would capture the constraint on the association that I'm thinking
might not be so uncommon. Maybe extending ActiveRecord.

A change of schema would depart from the business need of he data
architecture.