Doctrine 1.2 hydration fails with HYDRATION_RECORD, but works with HYDRATION_ARRAY

Question

I have a code that runs perfectly with Doctrine_Core::HYDRATION_ARRAY, but crashes with Doctrine_Core::HYDRATION_RECORD. The page is loading for about two minutes and shows standard browser error message, which is something like

Connection to the server was lost during the page load.

(I have localized browser, so that's not the exact error message, but translated).

Using mysql command line 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             |
+-----+--------+-----------------+--------+---------+------+-------+------------------+

The code itself:

 $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);

So I think that query is not populated with correct SQL. Hovewer, $q->getSqlQuery() outputs the correct SQL that runs perfectly if executed via command-line or phpMyAdmin.

Server configuration:

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

Everything runs on localhost, so that's not a connection issue.

The amount of data for that specific query is very small - about a dozen records, so it's nothing to do with memory or time limits. safe_mode is off, display_errors is on ,error_reporting is 6135.

Could somebody point to some hints or caveats I'm missing?

UPDATE: what's most weird that it works with HYDRATION_RECORD from time to time.

UPDATE2: it crashes when I'm trying to fetch something from the query, e.g. getFirst(). With no fetching it works, but I really don't need a query form which I can't fetch data.

UPDATE3: I've workarounded this issue, but I'm still interested, what's going on.

Update 4:

Sql query:

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)

Output:

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... 

So, the query itself is OK, data fectched as expected. Do you need models definition?

Update 5 When running query with HYDRATE_RECORD httpd.exe consumes 100% of one of the CPU cores.

Final Update Don't know why, but now it works... Haven't changed anything. Looks like it just was waiting when I place a bounty on this question. :) But still, as I already have placed a bounty, any idea of what's the difference between HYDRATE_ARRAY and HYDRATE_RECORD that might crash the script is appreciated.

Answer 1

I've seen a similar behavior when dumping in some way (print_r, var_dump, and so on) the whole record set or just a single record. This is caused by the fact that Doctrine uses an high structured class hierarchy which contains a lot of circular references. This obviously is not true when you use Doctrine_Core::HYDRATION_ARRAY.

So any of the mentioned functions (but I think that can be some other way to reproduce that) will begin an endless loop which causes 100% cpu usage until it reaches a kill point.

Don't know if this can help in your case.