Проблема согласованности кэша APC

Question

Я встроил в наш объект кэширование слоя ORM.По сути, в качестве ключа используется хеш SQL-запроса, а значение содержит коллекцию объектов из набора результатов БД.Однако это создает проблему, если один из объектов в наборе результатов обновляется, кэшированный набор результатов не включает обновленный объект.Нет последовательности записи.Как реализовать согласованность записи?

Спасибо

ОБНОВЛЕНИЕ: В настоящее время у меня есть класс ObjectWatcher, который обрабатывает объекты, которые кэшируются, и их ключи.Объекты кэшируются с помощью извлекаемых ключей, поэтому для класса Person это, например, Person.101.SQL-запрос хешируется, и ключ отображается на объект Dependency, в котором есть список зависимых объектов.Таким образом, SELECT * FROM person может возвращать объект зависимости от APC, который отображается на Person.101 и Person.102, итоговая коллекция построена из этого объекта зависимости.Это прекрасно работает для обновления одного объекта.Поэтому, если я обновлю Person.101 и поместу новый объект обновления в APC, перезаписав устаревший, при запуске более старого запроса этот обновленный объект будет помещен в этот набор результатов, что может быть неверным.Мне нужен способ очистить не только объект из памяти, но и весь объект Dependency, который содержит ссылку на обновленный объект.В APC есть способ искать ключи, содержащие или значения, содержащие или фильтровать ключи и значения?

Answer 1

Этот вопрос не имеет отношения к БТР.
Вам нужно решить, как данные будут храниться в APC (или любом другом хранилище). Если вы хотите обновить значение ключа в APC, когда объект будет изменен - ​​это возможно, только когда Object будет знать ключ (хэш запроса) и этот объект сможет собирать все данные из других объектов, извлеченных этот запрос. Все это звучит как абсурдная идея.

Любая модель должна быть разработана с принципом единой ответственности, поэтому, если вы хотите кэшировать целые объекты (это тоже не очень хорошая идея), то создайте уникальные ключи для каждого объекта.
Кроме того, объекты не должны заботиться о том, как они будут храниться (кэшироваться) и где. Итак, вам нужен еще один объект, который будет управлять кэшированием объектов.

И я рекомендую кешировать не целые объекты, а только значения записей в БД, что занимает много времени для их извлечения из БД.

Но если вы все еще хотите использовать хеш SQL-запроса в качестве ключа, тогда вы можете использовать теги и записывать «имена» объектов в эти теги. Например, если в результирующем наборе у вас есть объекты Person, Employer и Customer, то ключ будет иметь теги «person», «Employer» и «Customer». И, когда объект Customer будет изменен, вы можете удалить из кеша все ключи, которые помечены тегом «customer».
Но, в любом случае, это не ответственность объекта Customer, все это должно управляться другим объектом.

Вопрос отредактирован, поэтому я тоже отредактирую свой ответ:)

Теги не являются частью APC, являются частью оболочки. Теги - очень полезная вещь и очень удобная для вашего случая.

которые содержат ссылку на обновленный объект

Теги могут быть этой ссылкой. Вам не нужно искать ключи по тегу, вам нужно просто удалить все ключи, связанные с этим тегом (чтобы данные оставались актуальными), и у этой оболочки есть существующий метод для этого.

В примерах:
Пусть у нас есть запрос SELECT * FROM persons WHERE email <> '' - кэшированный результат этого запроса будет помечен тегом «персона».

Итак, когда мы обновим любой объект Person, мы удалим все ключи, помеченные тегом «person», поэтому наш результат для запроса SELECT * FROM persons WHERE email <> '' будет удален, и в следующем запросе наш скрипт сгенерирует новый ( фактическое) значение.