使用HYDRATION_RECORD，Doctrine 1.2水合作用失敗，但與HYDRATION_ARRAY一起使用

Question

我有一個與Doctrine_Core::HYDRATION_ARRAY完美Doctrine_Core::HYDRATION_ARRAY的代碼，但是與Doctrine_Core::HYDRATION_RECORD崩潰了。 該頁面加載大約兩分鍾，並顯示標准的瀏覽器錯誤消息，這是類似的

Connection to the server was lost during the page load.

（我有本地化的瀏覽器，所以這不是確切的錯誤消息，但已翻譯）。

使用mysql命令行Show processlist輸出

+-----+--------+-----------------+--------+---------+------+-------+------------------+
| 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。 Hovewer， $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

一切都在localhost上運行，所以這不是連接問題。

該特定查詢的數據量非常小 - 大約十幾條記錄，因此它與內存或時間限制無關。 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占用其中一個CPU內核的100％。

最終更新不知道為什么，但現在它的工作原理......沒有改變任何東西。 當我在這個問題上放置賞金時，看起來只是在等待。 :)但是，由於我已經放置了賞金，因此可以了解可能導致腳本崩潰的HYDRATE_ARRAY和HYDRATE_RECORD之間的區別。

Answer 1

在以某種方式（ print_r ， var_dump等）轉儲整個記錄集或只是一條記錄時，我看到過類似的行為。 這是因為Doctrine使用了一個包含大量循環引用的高結構化類層次結構。 當您使用Doctrine_Core::HYDRATION_ARRAY時，這顯然不是這樣。

因此，任何提到的功能（但我認為可以通過其他方式重現）將開始無限循環，導致100％的CPU使用率，直到達到殺戮點。

不知道這對你的情況是否有幫助。

Answer 2

我在Doctrine 1.2中遇到了類似的問題，並發現PHP由於超出內存限制或執行時間而報告了FATAL錯誤，或者有時情況甚至導致PHP導致分段錯誤。

您可以在Apache錯誤日志文件中找到這些錯誤。 在我的OS X盒子上，這些文件位於/var/log/apache2/error_log 。 您可以在PHP配置中增加允許的內存或最大執行時間。

在我的情況下，它是由從數據庫中提取的記錄數量導致過多的內存消耗引起的。 保濕Doctrine_Records似乎是一段相對艱難的事情。

出於好奇，您對結果有多少行？