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 received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Search Discussions

  • Frederick Cheung at Nov 2, 2011 at 8:35 am

    On 2 Nov 2011, at 07:13, doug316 wrote:

    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.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Fullware at Nov 3, 2011 at 3:38 pm
    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.
    On Nov 2, 1:34 am, Frederick Cheung wrote:
    On 2 Nov 2011, at 07:13, doug316 wrote:








    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.








    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
    To post to this group, send email to rubyonrails-talk@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedNov 2, '11 at 7:13a
activeNov 3, '11 at 3:38p
posts3
users2
websiterubyonrails.org
irc#RubyOnRails

2 users in discussion

Fullware: 2 posts Frederick Cheung: 1 post

People

Translate

site design / logo © 2021 Grokbase