【问题标题】:Doctrine 1.2 hydration fails with HYDRATION_RECORD, but works with HYDRATION_ARRAYDoctrine 1.2 水合因 HYDRATION_RECORD 失败,但适用于 HYDRATION_ARRAY
【发布时间】:2011-10-27 06:57:06
【问题描述】:

我的代码在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。但是,$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_modeoffdisplay_errorsonerror_reporting6135

有人能指出我遗漏的一些提示或注意事项吗?

更新:最奇怪的是它不时与HYDRATION_RECORD 一起工作。

UPDATE2: 当我尝试从查询中获取某些内容时,它会崩溃,例如getFirst()。没有获取它可以工作,但我真的不需要我无法获取数据的查询表单。

UPDATE3:我已经解决了这个问题,但我仍然对发生了什么感兴趣。

更新 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% 的 CPU 内核之一。

最终更新 不知道为什么,但现在它可以工作了......没有改变任何东西。当我在这个问题上悬赏时,它似乎只是在等待。 :) 但是,由于我已经提供了赏金,对于 HYDRATE_ARRAYHYDRATE_RECORD 之间可能导致脚本崩溃的区别的任何想法表示赞赏。

【问题讨论】:

  • 当通过命令行或 phpMyAdmin 运行时,您能否显示一些生成查询的示例输出?只是列名和一行数据就可以了。此外,您的 MySQL 或 Apache 错误日志中是否有任何线索? (我想知道在水合记录时是否内存不足,但不是数组,它会更小......)
  • 不,我检查了每一个日志。 :) 另外,那是在启用了所有错误报告的开发机器上(我很确定)。我将在几分钟内运行该查询并更新帖子。
  • 顺便说一句,当您执行WHERE fact.deckid = <value> 时,对fact 执行左连接有什么意义?这不只是一个 INNER JOIN,真的吗? (因为fact 中必须存在一行,deckid 才能具有值...)
  • 嗯,对,但这确实解决了问题。问题是它与 HYDRATE_ARRAY 一样工作,但不适用于 HYDRATE_RECORD

标签: php mysql doctrine doctrine-1.2 php-5.2


【解决方案1】:

在以某种方式(print_rvar_dump 等)倾倒整个记录集或仅倾倒单个记录时,我看到了类似的行为。这是因为 Doctrine 使用了包含大量循环引用的高结构化类层次结构。当您使用Doctrine_Core::HYDRATION_ARRAY 时,这显然不是真的。

因此,任何提到的函数(但我认为可以通过其他方式重现)将开始一个无限循环,导致 100% 的 cpu 使用率,直到它达到终止点。

不知道这对你的情况是否有帮助。

【讨论】:

  • 感谢您的回答,但我知道这一点。没有使用递归打印功能。此外,这个“错误”是由 Doctrine 对象中的循环引用引起的,我安装了 XDebug,最大深度设置为 3。所以,当我不小心转储 Doctrine 对象时,我能够看到输出。在这种情况下,我有 100% 的 CPU 负载,没有输出,最终断开了连接。
【解决方案2】:

我在 Doctrine 1.2 上遇到过类似的问题,发现 PHP 由于超出内存限制或执行时间而报告了一个 FATAL 错误,或者有时甚至导致 PHP 导致分段错误。

您可以在 Apache 错误日志文件中找到这些错误。在我的 OS X 机器上,这些文件位于 /var/log/apache2/error_log 中。您可以在 PHP 配置中增加允许的内存或最大执行时间。

在我的例子中,这是由于从数据库中获取的记录数量过多导致内存消耗过多。保湿 Doctrine_Records 似乎有时是一件相对困难的事情。

出于好奇,您希望结果中有多少行?

【讨论】:

  • 那条记录只输出十几条记录。我知道如何增加内存限制,实际上它现在设置为 512Mb,所以我怀疑它是否与此有关。在发布此消息之前,我已经检查了 PHP 错误日志和 Apache 错误日志,其中没有任何线索。我启用了错误报告,所以我会看到错误消息(如果有)。所以,谢谢你的回答,但它不正确:)
猜你喜欢
  • 2019-09-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-05-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多