Cashier-stripe: Billable->Subscription relationship is inconsistent
Billable->subscriptions() guesses the foreign key based on the Stripe model, but Subscription->user() always assumes the local key is 'user_id', regardless of the Stripe model. Seems like both sides of the relationship should be consistent. I submitted a PR, but it was closed.
dsshafer
All 9 comments
Possible fixes: 1) Update Billable->subscriptions() to specify the foreign key as 'user_id' (per the PR); 2) Update Subscription->user() to allow the framework to guess the local key name instead of always assuming 'user_id' (in the documentation, this would require a note on the subscriptions table schema that user_id may need to change to something else); 3) Include a note in the documentation explaining the inconsistency, with instructions to override the inherited subscriptions() relation on your Stripe model if necessary. Fix 1 seems the most correct, since the local key name is already being forced in Subscription->user().
dsshafer
on 14 Jan 2016
I have encountered exactly the same problem as you, however, I thought the best way to fix it would be option 2, and submitted a PR to guess the relation from the model which is passed through, with a manual override if needed. #265 - this was my PR but Taylor closed it, presumably because he thought this was a rare problem. I agree that the most common use case will use the User model, but it can't hurt to have it so that other models can be passed through too (especially since Cashier already asks for it!). I know it will make the naming convention slightly inaccurate but this could be changed at the next major release.
Can we have a rethink on this? @taylorotwell
nthndnn
on 19 Feb 2016
In my case, the Billable entity is an Organization with multiple Users.When I tested this, the only thing required to implement option 2) above was to remove the explicit reference to "user_id" in the Subscription->user() relationship; that's enough to allow the framework to guess the appropriate foreign key name. (The documentation would also need to be updated, to reflect that the "subscriptions" table schema may have to be adjusted if your Stripe model is something other than "User".)
dsshafer
on 19 Feb 2016
Maybe references to "user" should be changed to the more generic "billable"-- rename the relationship to Subscription->billable(), force the foreign key to be named subscriptions.billable_id, etc.
dsshafer
on 19 Feb 2016
What is everyone else doing in this case? Easy hack to fix for now, but feels dangerous.
dambridge
on 9 Mar 2016
I simply abandoned migrating my projects from 4.2 to 5.2.
Ralla
on 10 Mar 2016
@Ralla I'm in the middle of a 4.2 -> 5.2 migration as well at the moment. I'm going to put that on hold now until there's a solution to this.
kyranb
on 10 Mar 2016
@dsshafer - This sounds like the best option.
kyranb
on 17 Mar 2016
This has been fixed in #337 thanks to @Repox
nlassiter
on 13 Oct 2016
Related issues
cvcv01
路
3Comments
MarGul
路
5Comments
mehrancodes
路
5Comments
4UForever
路
3Comments
AnalyzeMe
路
5Comments
Most helpful comment
In my case, the Billable entity is an Organization with multiple Users.When I tested this, the only thing required to implement option 2) above was to remove the explicit reference to "user_id" in the Subscription->user() relationship; that's enough to allow the framework to guess the appropriate foreign key name. (The documentation would also need to be updated, to reflect that the "subscriptions" table schema may have to be adjusted if your Stripe model is something other than "User".)