Getting back into a maintainable state #1924
Replies: 2 comments 1 reply
-
@jleclanche thanks for your summary! |
Beta Was this translation helpful? Give feedback.
-
@jleclanche I think this is a must needed approach and I think the split on apps needs so that all FKs or rather the chain of FKs should completely be in 1 app. Otherwise adding or removing such apps will cause issues. And yes starting with And the other thing I would suggest is creating a module called And in this rewrite we should also switch over to django signals and have the webhooks dictionary be ordered in that it should allow the user to specify if they want their handler to run at the end (default) or at the beginning through a simple flag. And before we embark on this journey I think we should either merge or close all existing PRs and then use the latest state of master to do all dev on branch 3.0.0. What do you think? |
Beta Was this translation helpful? Give feedback.
-
With the explosion of models in Stripe since a few years ago, dj-stripe has become extremely hard to maintain. We are constantly chasing a moving target in terms of models, the models themselves are making the django databases too large, too cumbersome, and so on. This is affecting migration sizes as well, and it's just… not sustainable at all.
I don't like this state at all. I want to start a discussion on how we can get back to a maintainable state.
A few key points I want to address, all at once:
Back to basics. I think dj-stripe 3.0 will be a significant rewrite, to address all of the above.
At a high level, this is what I think I want to see:
ScheduledQueryRun
next release, since this is likely a harmless one to test on. Depending on what @dbartenstein thinks, we could do this for identity as well (since we are just now introducing it in 2.8)stripe_data
field, which contains everything from the upstream model's data, as json. We can feed that JSON into a Stripe object (not a djstripe one!) to turn it into a usable sdk object without having to keep our own stuff in sync. Now, we can keep tracking fields in the db if we need to index them; this will lead to a tiny bit of duplication but for simplicity's sake I think this is okay (we could otherwise have those be virtual fields but let's not, for the sake of db compatibility)._attach_objects_post_save_hook
, we probably missed something. The dj-stripe models should become really, really simple.Customer
model is supported from 2.x, but I believe everything else should be wiped.I hate planning for such a significant backwards incompatible release, but honestly, I do not see how we will be able to keep maintaining dj-stripe long-term without doing this.
Beta Was this translation helpful? Give feedback.
All reactions