This script has been replaced by a rake task a long time ago:
bundle exec rake karma:run # to run the specs once
bundle exec rake karma:start # to run the spec after each change
We don't need it any more and it doesn't work on my machine.
This script doesn't work anymore. It was written for old an Australian
production server. We have automatic backups now. And if we wanted to
take a backup manually, we should probably give it a meaningful name,
not using a script.
Apparently, there was a practice to archive branches by tagging them
"archive/branch-name" and then deleting them. We don't practice that
anymore and I would suggest to not start doing it again. Our setup is a
bit different now.
We now use our own forks for feature branches and can have our own,
individual archiving practices in our forks. There is no need to have a
central graveyard of people's "work after progress".
The old feature branches we used to have in the central repository got
archived in another fork:
https://github.com/openfoodfoundation/openfoodnetwork-archive/
Branches associated to pull requests should be deleted after the pull
request has been closed. Github keeps a reference to those branches in
the pull request which is like an archive.
Special branches we still have and delete from time to time:
- transifex: Created for new translations, deleted afterwards.
- dependabot/*: Dependabot always creates pull requests. See above.
- 1-31-1-stable etc: They only live as long as they are supported.
I would also like to delete the old `archive/*` tags. They are in the
openfoodnetwork-archive repository and could confuse developers in the
main repository. Let's keep it clean.
This affects only top bar menu items for:
* Language
* Profile
This does not update the "Log in" menu item, because the currently
selected icon might not be self explanatory.
The `eql?` override has been added in very early commits but was
actually not used except in a test. It also caused performance problems
since each call to `eql?` would issue two database queries. A developer
would unknowingly trigger these when using `exchanges.uniq`. A mistake
that could have happened again in the future.
I moved the implementation to the test that was actually using it and
made a second test a bit more explicit.
The implementation queried the database for each incoming variant that
was changed. This rewrite combines ActiveRecord relations so that it
creates only one query. This saves another 5-10% of execution time when
updating enterprise fees on production instances.
When an incoming exchange of an order cycle changes, the ProductsCache
queries all affected outgoing exchanges to update them. It was creating
a big collection of exchanges with duplicates and then calling `uniq`.
That call was hitting a custom implementation of `eql?` which is very
inefficient. And since `Exchange.eql?` is ignoring the order cycle id,
it was probably filtering too many exchanges from the collection.
Fixed bug: If two order cycles sell exactly the same variants to the
same shop, the two outgoing exchanges are seen as equal. When the
variants change, ProductsCache would only update one of those two
exchanges, leaving one order cycle out of sync. This case is very rare.
It only happens if there is a shop with two active order cycles selling
exactly the same.
The new uniqueness test looks only at the attributes that are later used
to refresh the cache. I measured a page speed improvement from 90
seconds to 3 seconds (30 times faster).
The `private` modifier doesn't affect class methods. Class methods have
to be declared as private separately. Also using more guard clauses,
brackets and linebreaks.
