Hi folks,

during implementation of the identity map pattern for PersistentObject I
stumbled over a behaviour of ezcPersistentFindIterator, which I did not
expect:

If you use this iterator implementation to fetch objects iteratively,
object instances are re-used on every iteration step. This means, the
state of the object returned in an iteration step is overwritten on the
next iteration step. A short example to illustrate this some more:

<?php

$itr = $session->findIterator( ... );

$last = null;
foreach ( $itr as $current )
{
    if ( $last !== null )
    {
        var_dump( $last === $current );
    }
    $last = $current;
}

?>

This snippet will return true from the second iteration step on.

We had a discussion on IRC about this behavior, which revealed that it
is originally by intention. I personally dislike it quite much, since it
can lead to real debugging pain and is not intuitive from an OO
perspective. It also does not save that much (memory/time), since you
can simple unset a created object if you don't need it anymore.

My expectation of the find iterator class is to just fetch data from the
database sequentially, so you don't need to fetch all result rows at
once (like find() does). It should nevertheless create a new object for
each result row fetched.

In addition, the behaviour dooms the find iterator feature for the
identity map implementation. Since the iterator overwrites object
states, we need to disallow this way of fetching objects for the
ezcPersistentIdentitySession.

I personally would like to treat the current behavior of
ezcPersistentFindIterator as a bug and fix it to not overwrite object
states anymore.

How do you think about this?

Regards,
Toby
-- 
Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards

Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer

t...@ez.no | eZ Systems AS | ez.no
-- 
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components

Reply via email to