Дополнительные конъюнкты в активной записи. Откуда: откуда они берутся?
Я получаю очень странную ошибку базы данных, когда приложение CodeIgniter, с которым я работаю, пытается выполнить определенную операцию UPDATE.
Активная запись вызова:
$this->db->update('eval_events',
array('eval_event_totalscore'=>$result['average_score'],
'eval_event_average_totalscore=>$result['average_score']),
array('eval_event_id'=>$eval_event_id));
И сообщаемая ошибка:
Error Number: 1054
Unknown column 'id' in 'where clause'
UPDATE `eval_events` SET `eval_event_totalscore` = '40.0000', `eval_event_average_totalscore`
= '40.0000' WHERE `id` = '581' AND `id` = '581' AND `id` = '581' AND `id` = '581' AND `id` =
'581' AND `id` = '581' AND `id` = '581' AND `id` = '581' AND `id` = '581' AND `id` = '581' AND
`id` = '581' AND `id` = '581' AND `id` = '581' AND `id` = '581' AND `id` = '581' AND `id` = '581'
AND `eval_event_id` = '565'
А? Где, черт возьми, все эти дополнительные конъюнкты, включающие `id`, происходят?
Очевидно, я не передаю их, и мое чтение CI_active_record.php не дал мне никаких подсказок.
Три дополнительных фрагмента информации, которые могут иметь отношение к теме:
- Насколько я могу судить, этот сбой происходит только на моей машине для разработки. Похоже, что запрос в порядке на производственной машине.
- Если я закомментирую этот звонок
update(), следующий позвонитьupdate()искажается точно так же. - Значение «581» имеет значение в общем контексте операции, частью которой являются эти обновления, но это ключ в другой таблице (и в любом случае он связан со столбцом с именем `pid`, не `id`).
Это чувствует подобно коду Active Record, который кэшировал это id = 581, и что-то заставляет его выкашливать содержимое этого кэша в мой оператор UPDATE на этом этапе.
Я признаю, что я не понимаю, что такое Active Record start_cache()/stop_cache()/flush_cache() методы действительно должны быть полезны — но это не должно иметь значения, потому что grep -r говорит мне, что нет звонка start_cache() в любом месте кодовой базы приложения.
Просто ради ухмылки я попытался позвонить $this->db->flush_cache() непосредственно перед провалом update() позвони, но это ничего не изменило.
Я понятия не имею, где искать дальше, чтобы попытаться понять это.
Есть идеи? Кто-нибудь?
Решение
Хорошо: echo, var_export() а также debug_print_backtrace() в помощь.
Оказывается, есть функция, которая вызывается в общей сложности 16 раз перед функцией, которая делает сбой update() вызов. И 16 просто является числом дополнительных `id` = ‘581’ коннектов в неверном операторе UPDATE.
И в этой более ранней функции следующий код (я не писал любой этого мусора, кстати):
$this->db->where('id',$pid); // <=== WTF???
$sql = "SELECT id FROM project_score WHERE pid=$pid AND uid=$uid AND scoretype=1";
$result = $this->db->query($sql)->row_array();
Что не так с этой картиной?
Ну, кроме сомнительного выбора использования Active Record совсем,* Активная запись query() метод не использует ничего, что было сжато предыдущими вызовами where(),
Следовательно, эта очередь из 16 фальшивых условий все еще висит, ожидая, чтобы присоединиться к первому ничего не подозревающему update() (или же select()или как угодно) вызов, который приходит вместе.
Почему это не происходит в производственной системе?
Ну, в моей системе разработки я временно что-то закомментировал еще (что на самом деле меня не волновало), что не помогло из-за некоторой недостающей конфигурации в моем локальном PHP — которую я тогда не испытывал как перестройку.
Очевидно, что все, что я прокомментировал, содержало вызов Active Record, который навязал ему очередь из 16 условий — но они оказались благоприятными для этого конкретного вызова.
Sheesh!
* Так чья же идея была в этой пародии на «Active Record»?
Как хорошо иметь такие функции, как where() что очередь вещей на Глобальный объект? Разве не лучше было бы сделать каждый оператор SQL отдельным объектом, чтобы ошибки, допущенные при его создании, не могли повредить другой в совершенно другой части приложения?
Другие решения
Других решений пока нет …
detector