Replies: 1 comment 3 replies
-
Take a look at event sourcing, that's probably a good solution to this problem. Use data objects to store the percentages at a point in time which are copied from the settings. That keeps your settings dynamic and you can also have different versions of their values. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This package is a good peice of work. For most use cases it's sufficient. However I strongly feel that the settings change over time and at some obvious point in time, the historical changes get lost with updated values.
Here is an exmplae usage-
Suppose there is a system for rewarding its customers a certain cashback points based on the puchases they have in last month.
The configuration for how much percentage of actual purchase will be rewarded as cashback is kept in settings table.
This fine as long as the percentage doesn't change. But as soon as we change the percentage, we lost track of what was the rewarded percentage for old purchases.
It makes me think that if there would have been a version number in the settings we could easily use that number while rewarding cashbacks and anytime we need to figure out the configuration for past rewards we can easily link them up with the version number.
Technically the settings classes whould accept a version number and populate the values based on this.
I hope this makes sense.
Thanks
Beta Was this translation helpful? Give feedback.
All reactions