The check-then-act pattern in `register_activity_spike` has been
replaced with `find_or_create_by!` to eliminate the race condition
that could lead to creating multiple activity spikes for a card. To
support this change, the `card_id` index on `cards_activity_spikes`
has been made unique.
ref: https://app.fizzy.do/5986089/cards/3063
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.
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.
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.
- Switch to binary 16 for UUID keys
- Remove AccountScopedRecord base class, all model use binary uuids now
- Fix the search sql to serialize uuids properly
- Patch the MySQL schema dumper to output binary lengths
These are mainly because the fixture's UUIDs are deterministic rather
than time-sortable, and more places where we need to correct the fixture
IDs as well.
Create search_index_0 to search_index_15 tables and shard each index by
account id. MySQL has no ability to pre-filter fulltext indexes by
another field so this is the best bet for improving performance.
Each fulltest index internally creates 11 sub tables (see
https://dev.mysql.com/doc/refman/8.4/en/innodb-fulltext-index.html) so
actually we have 192 tables in total here.
The search_index table name is generated dynamically based on the
account_id.
Stanko K.R.