2. Таблица сервисов
● Записи невозможно дублировать из-за составного уникального
ключа:
– customer_id
– entity (обычно – имя домена)
– serviceplan_id
● Сервисы нужно как-то удалять
● Хочется сохранить “устаревшие” записи о сервисах
● Данные связанных таблиц тоже хочется сохранить (оплата,
конфигурация, история статусов, и т.д.)
3. Таблицы “*_history”
● Создать таблицу service_history (где нет условия
уникальности) и копировать туда сервисы
● Для каждой связанной таблицы создать таблицу с
суффиксом _history, и копировать туда “старые” записи
4. Отдельная БД
● При удалении переносить все данные в отдельную БД
– при удалении
– или заранее, репликацией нужных таблиц
● Таблица сервисов будет отличатся, их:
– переносить “вручную” при удалении
– реплицировать, но чтобы они никогда не удалялись
5. “Прятать” старые сервисы в промежуточном
слое
● Moose ↔ DBIx::Class ↔ DBI ↔ MySQL
● Можно переопределить search_rs() в
My::DB::ResultSet::Service
Fetchers
7. Переопределяем Service resultset
● Использование resultset_attributes()
– Ненадежно, может исчезнуть в следующих версиях!
● Переопределить resultset_attributes() в
My::DB::Result::Service
● resultset_attributes() не знает о current_source_alias()!
● Можно имитировать в My::DB::ResultSet::Service::new()
12. Один тест не работал
● prefetch + where
– where используется в запросах, где есть prefetch, для
добавления условий
13. Написал в рассылку DBIx::Class
● ...и заодно в IRC
● ribasushi был занят :)
14. В итоге
● Удалили ключ distinct_service – оставили только ограничения в коде
● CREATE VIEW service_v AS SELECT * FROM service
WHERE status != 'deleted';
● My::DB::Result::Service → My::DB::Result::Service::All
sub delete { shift>update({ status => 'deleted' }); 1; }
● My::DB::Result::Service:
use parent 'My::DB::Result::Service::All';
__PACKAGE__>table('service_v')
1;