Uncarved

I’ve recently been working on Symfony / Propel projects that deal with particularly large data sets. In such cases, Propel’s documentation recommends a “lazy hydration” approach.

This “lazy hydration” of Propel’s looks like this:

  [#!php]
  // query all the author entities as a Creole ResultSet
  $rs = AuthorPeer::doSelectRS( new Criteria() );

  while( $rs->next() )
  {
    $author = new Author();
    $author->hydrate( $rs );
    echo "{$author->getLastName()}, {$author->getFirstName()}";
  }

The code above does the following:

1. it queries the database for all records in the author table, and loads it into a Creole ResultSet object.
2. enters a loop, iterating over each result (ie, table row) in the ResultSet, and with each of its records, it:
   1. creates a new, empty Author object
   2. hydrates the empty object with the data in the ResultSet‘s current row
   3. writes the author’s last and first name to the output buffer

In this way, only one Author instance is in use at any given time. Each iteration discards the previous instance and creates a new one.

But I hate it — it’s ugly and unwieldy.

This overt use of the ResultSet object is an awkward practice when using an ORM. The primary design goal of ORMs is to allow the developer to work at a higher level of abstraction than SQL queries and database result sets.

So what should it look like? Read more…

Tutorials announcement, development, laziness, PHP, Propel, Symfony