Гидратация Doctrine 1.2 не работает с HYDRATION_RECORD, но работает с HYDRATION_ARRAY - PullRequest
Новая
       28

Гидратация Doctrine 1.2 не работает с HYDRATION_RECORD, но работает с HYDRATION_ARRAY

7 голосов
/ 15 августа 2011

У меня есть код, который отлично работает с Doctrine_Core::HYDRATION_ARRAY, но вылетает с Doctrine_Core::HYDRATION_RECORD. Страница загружается около двух минут и показывает стандартное сообщение об ошибке браузера, что-то вроде 

Connection to the server was lost during the page load.

(У меня локализован браузер, поэтому сообщение об ошибке не точное, но переведено).

Использование командной строки mysql Show processlist output 

+-----+--------+-----------------+--------+---------+------+-------+------------------+
| Id  | User   | Host            | db     | Command | Time | State | Info             |
+-----+--------+-----------------+--------+---------+------+-------+------------------+
| 698 | root   | localhost:53899 | NULL   | Query   |    0 | NULL  | show processlist |
| 753 | *user* | localhost:54202 | *db1*  | Sleep   |  102 |       | NULL             |
| 754 | *user* | localhost:54204 | *db2*  | Sleep   |  102 |       | NULL             |
+-----+--------+-----------------+--------+---------+------+-------+------------------+

Сам код: 

 $q = Doctrine_Query::create()
        ->select("fc.*")
        ->from("Card fc")
        ->leftJoin("fc.Fact f")
        ->where("f.deckid=?", $deck_id);
  $card = $q->execute(array(), Doctrine_Core::HYDRATE_RECORD);
  //Commenting the above line and uncommenting below line leads to an error
  //$card= $q->execute(array(), Doctrine_Core::HYDRATE_ARRAY);

Так что я думаю, что запрос не заполнен правильным SQL. Однако, $q->getSqlQuery() выводит правильный SQL, который отлично работает, если выполняется через командную строку или phpMyAdmin.

Конфигурация сервера: 

Apache/2.2.4 (Win32) mod_ssl/2.2.4 OpenSSL/0.9.8k mod_wsgi/3.3 Python/2.7.1 PHP/5.2.12
Mysql 5.1.40-community

Все работает на локальном хосте, так что это не проблема подключения.

Количество данных для этого конкретного запроса очень мало - около десятка записей, так что это не имеет никакого отношения к памяти или ограничениям по времени. safe_mode равно off, display_errors равно on, error_reporting равно 6135.

Может ли кто-нибудь указать на некоторые подсказки или предостережения, которые я пропускаю?

ОБНОВЛЕНИЕ: самое странное, что время от времени он работает с HYDRATION_RECORD.

UPDATE2: происходит сбой при попытке извлечь что-либо из запроса, например, getFirst(). Без извлечения это работает, но мне действительно не нужна форма запроса, из которой я не могу получить данные.

ОБНОВЛЕНИЕ 3: Я обошел эту проблему, но мне все еще интересно, что происходит.

Обновление 4:

Запрос SQL: 

SELECT f.id AS f__id, f.createdat AS f__createdat, f.updatedat AS f__updatedat,
    f.flashcardmodelid AS f__flashcardmodelid, f.source AS f__source, 
    f.content AS f__content, f.md5 AS f__md5 
FROM flashcard f 
LEFT JOIN fact f2 ON f.id = f2.flashcardid AND (f2.deleted_at IS NULL) 
WHERE (f2.deckid = 19413)

Выход: 

f__id   f__createdat            f__updatedat            f__flashcardmodelid     f__source           f__content
245639  2011-08-05 20:00:00     2011-08-05 20:00:00     179                     jpod lesson 261     {"source":"\u7f8e\u5473\u3057\u3044","target":"del...

Итак, сам запрос в порядке, данные отображаются в соответствии с ожиданиями. Вам нужно определение модели?

Обновление 5 При выполнении запроса с HYDRATE_RECORD httpd.exe потребляется 100% одного из ядер ЦП.

Окончательное обновление Не знаю почему, но теперь это работает ... Ничего не изменилось. Похоже, он просто ждал, когда я вознагражуюсь за этот вопрос. :) Но, тем не менее, поскольку я уже разместил награду, любая идея о том, в чем разница между HYDRATE_ARRAY и HYDRATE_RECORD, которая может привести к сбою сценария, приветствуется.

Ответы [ 2 ]

1 голос
/ 26 августа 2011

Я видел похожее поведение при сбросе каким-либо образом (print_r, var_dump и т. Д.) Всего набора записей или только одной записи. Это связано с тем, что Doctrine использует высокоструктурированную иерархию классов, которая содержит много циклических ссылок. Это очевидно не так, когда вы используете Doctrine_Core::HYDRATION_ARRAY.

Таким образом, любая из упомянутых функций (но я думаю, что это может быть каким-то другим способом воспроизвести это) начнет бесконечный цикл, который приводит к 100% использованию процессора, пока не достигнет точки уничтожения.

Не знаю, может ли это помочь в вашем случае.

0 голосов
/ 18 августа 2011

У меня была похожая проблема с Doctrine 1.2, и я обнаружил, что PHP сообщил об ошибке FATAL из-за превышения лимита памяти или времени выполнения, а иногда даже из-за ситуации PHP вызывал ошибку сегментации.

Вы можете найти эти ошибки в файле журнала ошибок Apache. На моем OS X box эти файлы находятся в /var/log/apache2/error_log. Вы можете увеличить разрешенную память или максимальное время выполнения в вашей конфигурации PHP.

В моем случае это было вызвано количеством записей, извлеченных из базы данных, что вызвало чрезмерное потребление памяти. Увлажнение Doctrine_Records кажется довольно трудным делом в некоторых случаях.

Просто из любопытства, сколько строк вы ожидаете в своем результате?

...