-
Notifications
You must be signed in to change notification settings - Fork 0
Ru:TaggableSmartHandler
Пока проще всего получилось описать работу этих классов на примерах.
Пусть у нас будут две таблички и соотвествующие бизнес объекты - User и City (таблицы users и cities). Каждый из пользователей имеет обязательное свойство city ссылающееся на город. У этих таблиц могут быть еще дополнительные поля но заранее, думаю, описывать их не имеет смысла, они будут носить эпизодический характер в примерах.
Если мы хотим получить список всех пользователей, то делаем запрос вида SELECT * FROM users; При этом единственный тэг который можно привязать к такому запросу - это тег с названием таблицы. При этом при изменении любого пользователя запросы по этому тэгу должны раскешиваться.
Тоже самое касается и запросов SELECT * FROM users WHERE users.name = 'Ivan' или, например, ... WHERE users.birthday IS NOT NULL. Все эти запросы привязываются к единственному тегу на основе названия таблицы users.
Если нужно искать пользователей которые живут в конкретном городе SELECT * FROM users WHERE city_id = 33, то запрос будет привязан к тегу "cities|33". Почему такой запрос повешенный на тэг из другой таблицы будет актуален (или что нужно делать что бы он был актуален)?
Например, мы обновляем пользователя (c id=55) у которого city_id = 33. В таком случае необходимо обновить следующие теги:
- тег users|55 (т.е. раскешиваем самого пользователя)
- тег users (нужно сделать неактуальными все общие запросы)
- теги связанных объектов на которые ссылается текущий, в данном случае cities|33
- если у пользователя меняется само свойство city_id, то нужно раскешить как тэг старого города так и нового
Т.к. в списке тегов для раскешивания гарантированно есть cities|33, то подобного запрос будет всегда актуален при измении пользователя. Тоже самое касается и обновления города. Как только мы изменяем город 33, то раскешиваются запросы с тегом cities|33 и запрос сохранит актуальность при изменении города.
Если попадаются сложные запрос с JOIN'ами, то тэги создаются по названию таблиц, т.к. запрос вида SELECT * FROM users JOIN cities ON cities.id = users.city_id WHERE cities.name = 'Moscow' будет бесхитростно повешен на два тега cities и users. При измении/добавлении записей в любой из этих таблиц следующий такой запрос будет браться из базы.