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:58:28 PDT
Message Well, I don't know... but I said that the way propel works now, if
you "lazy-hydrate", then even though you return N objects, they are
garbage collected properly and thus you only have 1 allocated at a
time; it's just a DIFFERENT instance.

I had horrible problems with unbounded memory consumption, even with
self-hydrating, because of the way the related items were stored. But
since you fixed that, I no longer have the problem and thus a new
"PropelResultSet" that had an iterator interface to automatically
lazy-hydrate would be a perfect and appropriate improvement.

Alan

On Oct 4, 2006, at 10:56 AM, Hans Lellelid wrote:

> Isn't Sven saying that FETCH_INTO will keep memory/resource use to a
> minimum? (Unlike current situation where you would have a new object
> allocated for each row returned.)
>
> Hans
>
> Alan Pinstein wrote:
>> But you still didn't answer my question? What is the benefit or
>> appropriate use of FETCH_INTO that otherwise wouldn't work? Why is it
>> needed at all?
>>
>> Alan
>>
>> On Oct 4, 2006, at 10:48 AM, Sven Tietje wrote:
>>
>>> Alan Pinstein wrote:
>>>
>>> hi alan,
>>>
>>>> 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?
>>>
>>> Ok... You are not a friend of FETCH_INTO - just mentioned it for
>>> reading and
>>> as possible option. If you know what it means: use it, where you
>>> need.
>>>
>>> By default propel should create a new instance for each row.
>>>
>>>> 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++;
>>>> }
>>>
>>> Yes, of course it works, but i`m a friend of comfort :D Having a
>>> resultset
>>> and option to set is nice :D
>>>
>>> $rs = MlsPropertyPeer::doSelect($c);
>>> // now just wanna read with some special calculation functions
>>> $rs->setMode(Pro​pel::ONE_OBJECT /*FETCH_INTO*/);
>>>
>>> foreach ($rs as $row) {
>>> //do stuff
>>> }
>>>
>>> Of course, the iterator can work internally the way you mentioned
>>> above.
>>>
>>> Was just an idea to discuss. What do you think of using FETCH_CLASS?
>>>
>>> Alan, i am not against your hydrate-method - just wanna discuss the
>>> implementation of pdo-features.
>>>
>>> Greets sven
>>>
>>> --------------------​--------------------​--------------------​--------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>>
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>
> --------------------​--------------------​--------------------​---------
> 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 | 10 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: