User.update_stripe called on every login / logout
opened this issue · comments
I believe the user model gets saved on every login/logout and therefore calls update_stripe. Is this the intended behaviour? I'm not sure we need to be pinging Stripe that much and updating our user's customer info that often.
Any thoughts?
Thanks for bringing up the issue. The example app includes the Devise trackable module which saves the user on login to increment the sign_in_count, current_sign_in_at, etc. attributes. Consequently, the before_save filter calls the update_stripe method for each login. To reduce the unneeded calls to Stripe, you could remove the :trackable parameter in the User model.
Perhaps there are other ways to resolve this? Do you have any suggestions?
For my production app, I separated the stripe details into a separate
subscription table with a has_one/belongs_to relationship. after_initialize
{ self.subscription ||= build_subscription } ensures that is is always
present. That made it much easier to edit the user subscription data
separately from the user record in the web app as I could deal separately
with the subscription model. Perhaps that is too complex for an example app.
Alternatively, you could add some checks in update_stripe to bail out if it
is not a new record and the plan name/email/name (etc.) hasn't changed. I
added few checks at the beginning of the method, then down lower separately
check to see if email/name changed to determine if I should call
customer.save and check if plan changed to see if I should call
customer.update_subscription.
On Fri, Mar 8, 2013 at 11:04 AM, Daniel Kehoe notifications@github.comwrote:
Thanks for bringing up the issue. The example app includes the Devise
trackable module which saves the user on login to increment the
sign_in_count, current_sign_in_at, etc. attributes. Consequently, the
before_save filter calls the update_stripe method for each login. To
reduce the unneeded calls to Stripe, you could remove the :trackableparameter in the User model.Perhaps there are other ways to resolve this? Do you have any suggestions?
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/65#issuecomment-14638112
.
I'd like to add the implementation you describe as an enhancement to the basic app. Can you make a PR with a branch that just adds the refactor you describe?
I'd be happy to, but it might take me a couple days before I can get to it. Were you thinking just the checks in update_stripe or the full separation of the subscriptions table?
Both. I think it would be helpful to show the subscriptions model. I understand you are busy so I appreciate whatever you can do.
@billvieux Are you able to provide the details on how you refactored it out into a separate table? Would be greatly appreciated! Thanks!
OK, a "couple of days" or "7 months". Pretty close, right? :) Sorry for the long delay. I forked the project and committed an example of splitting out the subscription table. I tried to minimize the code changes so make the core concepts clear. There is lots more you could do like separating out the controller / view for the subscription model.
Here is the commit with comments (both inline and overall):
billvieux@30a82ff
@DanielKehoe Let me know if you want a PR for my branch. Presumably you would need to update the tutorial and honestly the changes could probably use some additional RSpec tests.
Thanks for providing the example code. I won't ask you for a pull request because I need to revisit the app and do a rewrite for Rails 4. On my to-do list but I've got a book to launch first :-).
There is a new version of this application for Rails 4.2 using the Payola gem.