ref: https://3.basecamp.com/2914079/buckets/37331921/messages/8422006338
The script takes advantage of the fact that we can bind to the
existing untenanted database by adding it explicitly (and temporarily)
as a readonly shard to the database.yml, and so in the script
with_original_db is connected to the original database.
storage/tenants/%{tenant}/ is now the root directory for all
state stored for a particular tenant, including active storage and the
database.
We leave the existing files and production database in place after the
migration, in case we need to roll back (by reverting the code and
config).
We also don't do a granular active storage blob copy, since the
attachments are mostly on Account (and not on Bubble). Instead we
hardlink the blobs on disk (so we don't take up additional space with
duplicates).
Finally, we're manually adding the kamal-proxy hosts to the deploy
file, so that we can generate letsencrypt certs for the
subdomains. This is only intended to be a short-term solution, we'll
want something like a wildcard cert before we go live.
Because solid cache started using shard swapping when given a
`database:` key in https://github.com/rails/solid_cache/pull/219, and
Rails doesn't distinguish which database is being swapped and which
was locked.
Hopefully I can make a change upstream that will enable swap locking
only for a specific databases. Until then, let's just use a slightly
more verbose configuration to work around it.
Avoid infinite activity score orders
Items with a zero activity score were getting an activity sorting score
of -infinity, because we base the value on log2(score). Adjusting the
calculation avoids this edge case, by always basing the sorting score on
a non-zero number.
---------
Co-authored-by: Kevin McConnell <kevin@37signals.com>
This introduces a more dynamic system of activity scoring, to improve
the way bubbles "bubble up" due to their activity. There are a few
different parts we can tune here, and it's likely we'll need to make
adjustments once we get a feel for how this works in practice.
The basic idea here is:
- We assign points for certain types of event that happen on a bubble. A
boost gets 1 point, a comment gets 10 points, and so on.
- These points decay over time, at a rate of 50% per day. So old
activity is worth much less than new activity. Bubbles should rise up
quickly when acted upon, bit will float back down if left idle.
- Some comments can score higher than others: the first comment from
each person on a bubble is worth more (20) because it signals that
more people are getting involved; and comments that follow a comment
by a different author are also worth more (15) because that signals
there's ongoing conversation between people, not just a series of
notes being left by one individual.
In terms of implementation, we persist the score on the bubble
whenever it changes, but we handle the decay on the client side. That
allows us to cache the bubble representation without having to
continually change it while its activity decays.
We also keep a separate `activity_score_order` attribute on the model.
This can be used to sort the bubbles in order of "most active", without
having to think about the decay.
When displaying a bubble in the `creating` state, we were wrongly using
the plaintext version of the draft comment. This has the effect of
losing formatting whenever the page is saved and reloaded.
Mike Dalessio