2014-10-30 1 views
0

Я получаю очень странную ошибку базы данных, когда приложение CodeIgniter, с которым я работаю, пытается выполнить определенную операцию UPDATE.Дополнительные конъюнкты в активной записи WHERE clause: Откуда они берутся?

вызов Active Record является:

$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 не дало мне никаких подсказок.

Три дополнительные фрагменты информации, которые могут иметь отношение:

  1. Этот сбой происходит только на моей машине развития, насколько я могу сказать. Запрос кажется прекрасным на производственной машине.
  2. Если я прокомментирую этот звонок на update(), то после звонок update() будет поврежден точно так же.
  3. Значение «581» имеет значение в общем контексте операции, в которой эти обновления являются частью, но это ключ в другой таблице (и в любом случае он привязан к столбцу с именем `pid`, а не` id`).

Это чувствует как активный код записи в кэше, что `id` =«581», и что-то вызывает его кашлять содержимое этого кэша из в мое UPDATE заявление в этой точке.

Я признаю, что я не понимаю, что Active Record-х start_cache()/stop_cache()/flush_cache() методы действительно должны быть хорошо - но это не имеет значения, потому что grep -r говорит мне, что нет никакого вызова start_cache() в любом месте в кодовой базе приложения.

Только для усмешек я попробовал позвонить в $this->db->flush_cache() непосредственно перед сбоем вызова update(), но ничего не изменил.

Я понятия не имею, где искать рядом, чтобы попытаться понять это.

Любые идеи? Кто угодно?

ответ

0

ОК: 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() не ничего, что было squirreled далеко предшествующими вызовами where() использовать.

Следовательно, эта очередь из 16 фиктивных условий по-прежнему висит вокруг, ожидая, чтобы прикрепить себя к первому ничего не подозревающему update() (или select() или тому и другому) звоните, который приходит.

Почему это не происходит в производственной системе?

Ну, в моей системе разработки, я временно прокомментировал что-то еще (что меня действительно не беспокоило), что было неудачно из-за отсутствия отсутствующего конфига в моем локальном PHP, который мне не хотелось перестраивая право тогда.

По-видимому, все, что я прокомментировал, содержало вызов Active Record, который получил очередь из 16 условий, наложенных на него, - но они оказались доброкачественными для этого конкретного вызова.

Sheesh!

* Итак, чья идея заключалась в том, что пародия «Активная запись», во всяком случае?

Как неплохо иметь такие функции, как where(), что очереди на глобальных объект? Разве не лучший дизайн заключался бы в том, чтобы сделать каждый оператор SQL другим объектом, так что ошибки при построении одного не могли бы повредить другого в совершенно другой части приложения?

Смежные вопросы