Primarily this is in tests (which were caught by temporarily
introducing acts_as_tenant and enabling safety checks), but notably
action cable connections were not working properly, and that's now
fixed.
This adds an initial configuration for staging. Note that we are doing
this ahead of having the full infrastructure in all 3 DCs. So this
this will result in some cross-DC writes for now (e.g. we have a single cache in
IAD). We'll correct this as the infrastructure becomes available.
We'll also run jobs on every app server, until we split them out to
separate instances.
Lean on ActiveRecord models for searching and strip out the raw SQL.
Replaces the search_index_* tables with sharded search_records_* tables
as that allows us to use a Search::Record model name.
A Class is dynamically created for each record table shard so that we
and we can access it via the Search::Record.for_account(account_id)
method.
Schema:
- add account_id to tables it was missing from
- make account_id a required column everywhere
- add [account_id] indexes, or add `account_id` to existing indices
Models:
- add `belongs_to :account` to all models (default to using a domain
model's account whenever possible)
- add account_id in all the necessary fixtures
- add account_id to insert_all hashes
- pass account_id to a few initialize calls
Miscellaneous:
- update the import script to set account_id
Note that I'm not adding account_id to the join tables primarily
because I couldn't think of an easy way to populate it without making
it a full Join model, and that was more work than I have time to take
on right now.
In order for model ordering to work as expected in tests, we need to
keep two properties:
- Fixtures are all created in the past
- Models sort in the order that they were created
This allows us to do things like this:
post cards_path, params: { ... }
created_card = Card.last
When using UUIDv7 PKs rather than sequential integers, we have to make
sure a couple of things happen in order for this still to be true:
- Fixtures should generate deterministic IDs that translate to UUIDs
that would have been created in the past (i.e. before today)
- Newly created objects must have enough precision in their timestamps
so that they sort in the order they were created, and their random
component doesn't come into play.
To solve this, we use the deterministic numeric ID as a number of
milliseconds after an early year. And we ensure that the new timestamps
we create have sub-millisecond precision.
Mike Dalessio