Опрос: $db->insert() и ON DUPLICATE в вашем любимом квери билдере или ORM

[Absinthe]

То есть, должно быть 100% покрытие моделями. Никогда не пишем голый SQL, любые операции с данными - только через AR.

Вопрос: Так в реальной жизни бывает?

DQL.

 

[A1x]

А вот такой ещё вопрос, ко всем.
То есть, должно быть 100% покрытие моделями. Никогда не пишем голый SQL, любые операции с данными - только через AR.

Вопрос: Так в реальной жизни бывает?

не бывает, ORM не исключает использования plain SQL

ведь действие ON DUPLICATE, NOW, filed = filed + 1 - это магия происходящая внутри базы и мы теряем контроль над данными. т.к. база уже не соответствует данным в Identity map или кешах.

кеши надо не забывать вовремя сбрасывать, на то они и кеши

 

[fixxxer]

Проблема orm-ов как раз в отсутствии нормального управлением кэшами и инвалидацией.
Что-то похожее на решение этого вопроса я видел только в onphp, хотя доктрину2 я честно ниасилил, может, и там как-то можно.

 

[A1x]

если мы разрешаем использование чистого SQL (а запретить его вряд-ли получится)
то сделать инвалидацию кеша на уровне ORM не получится, остается только кеш запросов на уровне соединения с БД

 

[Вурдалак]

сделать инвалидацию кеша на уровне ORM не получится

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

 

[Koc]

А если мы в консольной комманде считаем что-то и заносим/обновляем 100к строк (insert select ODKU) - разворачивать на запросы в цикле + транзакции?

 

[fixxxer]

если мы разрешаем использование чистого SQL (а запретить его вряд-ли получится)
то сделать инвалидацию кеша на уровне ORM не получится, остается только кеш запросов на уровне соединения с БД

Получится в частном случае - когда все параметры выборки являются одновременно параметрами кэширования. Например, все, что идет в where, также идет в имя memcached-ключа.

Более того. Если используется внешнее кэширование (мемкэш тот же), это единственно правильная стратегия, обеспечивающая вменяемый cache hit/miss ratio.

И, да, ровно те же параметры используется для инвалидации. Здесь помогут memcached-тэги.

Тут, кстати, становится совершенно неважно, используется plain SQL, билдеры, table gateway, AR или еще что.

 

[A1x]

Тут, кстати, становится совершенно неважно, используется plain SQL, билдеры, table gateway, AR или еще что

ну так это и получается кеш запросов на уровне соединения с БД

Например, все, что идет в where, также идет в имя memcached-ключа.

какая польза от такой схемы когда одну и ту же запись можно извлечь по одному параметру в where, а модифицировать по другому
что-то я не пойму

Единственное что приходит в голову - использовать в качестве тегов кеша имена таблиц,
ну это практически тоже самое что в MySQL Query Cache

 

[fixxxer]

ну так это и получается кеш запросов на уровне соединения с БД

Угу, если бы он еще работал нормально, а не лочил все подряд хотя в последних версиях (по крайней мере перконы/марии) его, вроде бы, починили.

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

какая польза от такой схемы когда одну и ту же запись можно извлечь по одному параметру в where, а модифицировать по другому

Нельзя

 

[A1x]

Нельзя

почему нельзя?