Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] PropelResultset Iterator

propel
Discussion topic

Back to topic list

Re: [propel-dev] PropelResultset Iterator

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-10-04 07:15:25 PDT
Message Eeeew. FETCH_INTO sounds awful. I cringe at the idea of how many bugs
this causes with people not understanding references enough and
having FETCH_INTO cause terrible problems. It's 2006, we don't need
to re-use object shells! That is so not OO I don't even know how to
express it.

FETCH_INTO seems like some odd hack around GC unless I am not seeing
something.

Why is it needed?

In all of my scripts where I do batch processing, I do:

print "Querying for all properties to geocode...";
$c = new Criteria;
$c->add(MlsPrope​rtyPeer::GEOCODE_SCO​RE, 0); // only encode non-scored
items
$allPropsRS = MlsPropertyPeer::doS​electRS($c);
print "Done!\n";

$rowCount = 0;
$propArr = array();
while ($allPropsRS->next()) {
     $prop = new MlsProperty;
     $prop->hydrate($allPropsRS);
     // do stuff
     $rowCount++;
}

This doesn't consume unbounded memory. I'd think that if we create a
new "PropelResultSet" that when iterated provides hydrated objects,
that it will have the same effect as my code above and be nice and
clean and memory-thrifty.

PREVIOUSLY there was some really hairy internal reference-mongering
that causes GC to not work properly, but I complained enough :) and
Hans (I think) fixed it. So now it works beautifully.

Right? What am I missing?

Alan

On Oct 4, 2006, at 5:56 AM, Sven Tietje wrote:

> David Zulke wrote:
>> 1) memory consumption is a lot lower, e.g. when iterating over 1000
>> rows to display them, a row is fetched, the data is displayed, and
>> the GC can then go ahead and destroy the object.
>
> Think, that should be an option. Sometimes, i want do iterator over a
> resultset and to write baseobjects with special information into an
> array or
> something like that. PDO handles it the same way - Fetchmode gives you
> special options for fetching as object:
>
> http://de.php.net/ma​nual/de/function.pdo​statement-setfetchmo​de.php
> Using PDO::FETCH_CLASS will result into an object-instance for each
> row: 200
> rows in your resultset will give you 200 object-instances.
>
> PDO::FETCH_INTO will give you the same object-instance for each
> row: 200
> rows, but one object-instance.
>
> Having the same feature / option for propel would be nice:
>
> 1. One Instance for all rows
> $resultset = TablePeer::doSelect(new Criteria(), PROPEL::ONE_OBJECT);
>
> foreach ($resultset as $row) {
> echo $row //will give you the same object instance
> }
>
> I would use PROPEL::ONE_OBJECT to publish big resultsets. I don`t
> manipulate
> the object. With $myrow = clone $row it is possible to get my own
> instance
> of the row.
>
> 2. An Instance for each row
> $resultset = TablePeer::doSelect(new Criteria(), PROPEL::EACH_OBJECT);
> foreach ($resultset as $row) {
> echo $row //will result in Object#1, Object#2 ..... Object#200
> }
>
> Internally Propel uses clone() to create a single instance of each
> row.
>
>> 2) it opens the door for a potential
>> CategoryPeer::doSele​ctJoinProducts() support, where fetching 1:n
>> relations with a join would become possible.
>
> We should discuss to use
> PDOStatement::setFetchMode ( int PDO::FETCH_CLASS, string
> classname ) or
> PDOStatement::setFetchMode ( int PDO::FETCH_INTO, object object )
> instead of hydrate();
>
> I wrote a little script to test it:
>
> $stmt = $pdo->prepare('select name as `customer.name` from customer');
> $stmt->execute(array());
>
> class baseobject /*implements ArrayAccess*/ {
> private $data = array(
> 'customer.name' => null,
> );
>
> // for hydrate
> public function __set($key, $value) {
> $this->data[$key] = $value;
> }
>
> public function setName($value) {
> $this->data['customer.name'] = $value;
> }
>
> public function getName() {
> if (isset($this->da​ta['customer.name'])​) {
> return $this->data['cus​tomer.name'];
> }
>
> }
> }
>
> $blub = new baseobject;
> $stmt->setFetchM​ode(PDO::FETCH_INTO,​ $blub);
>
> $arg = array();
> while ($b = $stmt->fetch()) {
> // $b->setName('blah');
> var_dump($b->getName());
> }
>
> Implement ArrayAccess into an BaseObject could be a possibility,
> too. We
> should discuss it.
>
> Your opinion? I think to use the power of pdo would be nice.
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>

« Previous message in topic | 6 of 26 | Next message in topic »

Messages

Show all messages in topic

                 Re: [propel-dev] PropelResultset Iterator Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-04 08:13:23 PDT
Page: of 2 « Previous | Next »
Messages per page: