Replies: 1 comment
-
Should it go in the latest release? I think so, but it depends on how many people it is affecting. I also is a bit more complex since some people will have installed the original migration with the unique index already present, and some may have installed an earlier version of this package without the unique index. So it needs to be an optional migration that people can create and add to their application if they need it. Not sure how that would work, but having one available to use out of the box will help many, I suspect. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I noticed my
settings
table was growing each time the settings were saved. Yikes. Turns out if was a unique index added to the new-installs-only migration and a change to the way updates are handled using theupsert()
method. This method relies on the unique index, and the migrations from 2.x to 3.x and later do not add the unique index.So I created my own migration to fix this, which may be of use.
This is in the
up()
:The reverse of thus swaps the indexes back, but does not try to restore the duplicate settings:
You may not notice the problem, because rhe package gives you the latest setttings anyway, but I suspect by luck rather than design. I would also imagine memory and performance issues will start appearing if the settings are updates a lot. So check your
settings
table and try this migration if it has duplicate setting records or the unique index is simply not there.Do back up your settngs able first when trying this out for the first time. The
down()
method you may not need or use, but it's handy to have when running tests.Beta Was this translation helpful? Give feedback.
All reactions