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 11:29:47 PDT
Message Yeah, I don't get it either.

Right now, if you use XXXPeer::doSelect() you get an array with all
objects populated. If you plan on using *all* of the objects in the
result set, then it doesn't improve performance to hydrate them on-
demand; it just changes WHERE the cycles happen, but this doesn't
matter, because the overall performance won't change.

The result of doSelect() is iteratable, array-accessible, and isn't
re-hydrated on repeat access. So I *still* don't understand what you
are trying to achieve...

>> the second variant is a none-caching variant -> not use much
>> memory -> eg overview, only output etc...
>> of course, i could use an array, but i like oo-style for fetching
>> data. cause of this, i proposed to use FETCH_INTO - we can do it
>> another way. $object->getRelatedObject() is queried on the fly,
>> too. afterwards, data is gone.

This is not really true. While getRelatedObject() is on the fly, it's
only the FIRST TIME! So if you getRelatedObject() on the first
instance, then FETCH_INTO another row on top of this object, your
"new" object still is related to the one the previous row was. OOPS!
Have fun debugging that...

Alan

On Oct 4, 2006, at 2:20 PM, David Z├╝lke wrote:

> ???
>
> Isn't the first method nonsense? It's not any different from what
> we're doing right now.
>
> I think you're focusing too much on the performance of hydration.
> I'll try the direct PDO hydration idea later. I bet this will be
> incredibly fast. The only point where caching results makes sense
> is when we want to avoid querying the database again - that's the
> slow part.
>
> foreach($result as $row) {
> // each $row is hydrated on demand and NOT stored anywhere. under
> ideal circumstances, this would mean that memory use never exceeds
> the amount of memory needed for the largest row in the result set
> }
>
> This is what iterators would be about!
>
>
> David
>
>
> Am 04.10.2006 um 20:11 schrieb Sven Tietje:
>
>> hi alan,
>>
>> don`t want any war with you - i`m a friend of clean oo design,
>> too. perhaps i didn`t make myself clear. of course, i prefer a
>> single instance of each object.
>>
>> i`d like to have PropelResultset:
>>
>> class PropelResultset implements IteratorAggregate, ArrayAccess {
>> }
>>
>> foreach ($resultset as $row) {
>> private $cache = array(
>> 0 => BaseObject,
>> 1 => BaseObject,
>> .....
>> )
>>
>> // the objects are generated on the fly and on demand.
>> // the objects are cached
>> }
>>
>> fetching a special element afterwards will not generator a new
>> instance again - will return the object generated during the first
>> iteration.
>> $blah = $resultset[0] => [0] is already generated - you`ll get
>> the cached object back.
>>
>> or you iterate the resultset again => it`s not necessary to
>> hydrate the objects again - its just iterated about the interal
>> cached array containing the object instances.
>>
>> i think, that variante is the normal variant and its compatible to
>> all our applications.
>>
>> the second variant is a none-caching variant -> not use much
>> memory -> eg overview, only output etc...
>> of course, i could use an array, but i like oo-style for fetching
>> data. cause of this, i proposed to use FETCH_INTO - we can do it
>> another way. $object->getRelatedObject() is queried on the fly,
>> too. afterwards, data is gone.
>>
>> the first variant should still be the prefered and default variant
>> of handling data.
>>
>> greets sven
>>
>> Alan Pinstein schrieb:
>>> Why? Because re-using objects is:
>>>
>>> 1. BAD OO design... one instance == 1 LOGICAL instance. If you re-
>>> use it, you are pretty much breaking black-box. "Clients" of your
>>> objects don't expect this behavior, because it's bad OO design.
>>>
>>> What if in the course of using FETCH_INTO, you have some
>>> relationships:
>>>
>>> foreach (FETCH_INTO loop) {
>>> $myObj->setRelat​edObject($Y);
>>> }
>>>
>>> Well this is going to end up an awful mess, with no referential
>>> integrity in your object model.
>>>
>>> 2. There is no meaningful benefit to FETCH_INTO. Seriously, name
>>> one potential benefit of doing this. Are you thinking
>>> performance? Lots of things in OO would be faster if you break
>>> the OO... but it shouldn't be done.
>>>
>>> 3. With your example:
>>>
>>>> Now, i wanna publish a List of Person with their fullnames. I
>>>> don`t want to
>>>> change data or something -> just want to print table containting
>>>> the
>>>> fullname and some columns additional information. I`ll implement
>>>> a method
>>>> getFullname in my Object-Class:
>>>
>>> Ok great! That's a completely reasonable thing to want to do.
>>> HOWEVER, I don't see why getting back DISTINCT instances for each
>>> iteration prevents this from happening. It doesn't use more
>>> memory and it isn't much slower (only real speed difference is
>>> calling the constructor).
>>>
>>> However, I can promise you that getting back the SAME instance
>>> each time, but it having different data for *some* columns, will
>>> definitely cause you hours of painful debugging, followed by "Why
>>> am I using FETCH_INTO"?
>>
>> --------------------​--------------------​--------------------​---------
>> 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 | 21 of 26 | Next message in topic »

Messages

Show all messages in topic

PropelResultset Iterator Sven Tietje <tietje at topconcepts dot de> Sven Tietje <tietje at topconcepts dot de> 2006-10-02 01:43:05 PDT
     Re: [propel-dev] PropelResultset Iterator =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-02 02:04:45 PDT
     Re: [propel-dev] PropelResultset Iterator =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-03 05:13:38 PDT
         Re: [propel-dev] PropelResultset Iterator Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-03 06:07:14 PDT
         RE: [propel-dev] PropelResultset Iterator Sven Tietje <tietje at topconcepts dot de> Sven Tietje <tietje at topconcepts dot de> 2006-10-04 02:56:24 PDT
             Re: [propel-dev] PropelResultset Iterator Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-04 07:15:25 PDT
                 RE: [propel-dev] PropelResultset Iterator Sven Tietje <tietje at topconcepts dot de> Sven Tietje <tietje at topconcepts dot de> 2006-10-04 07:48:00 PDT
                     Re: [propel-dev] PropelResultset Iterator Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-04 07:52:18 PDT
                         Re: [propel-dev] PropelResultset Iterator hlellelid Hans Lellelid 2006-10-04 07:56:14 PDT
                             Re: [propel-dev] PropelResultset Iterator Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-04 07:58:28 PDT
                             Re: [propel-dev] PropelResultset Iterator =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-04 08:00:10 PDT
                                 Re: [propel-dev] PropelResultset Iterator hlellelid Hans Lellelid 2006-10-04 08:05:23 PDT
                                     Re: [propel-dev] PropelResultset Iterator hlellelid Hans Lellelid 2006-10-04 08:09:56 PDT
                                         Re: [propel-dev] PropelResultset Iterator Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-04 08:15:54 PDT
                                             Re: [propel-dev] PropelResultset Iterator hlellelid Hans Lellelid 2006-10-04 08:19:39 PDT
                             RE: [propel-dev] PropelResultset Iterator Sven Tietje <tietje at topconcepts dot de> Sven Tietje <tietje at topconcepts dot de> 2006-10-04 08:06:19 PDT
                                 Re: [propel-dev] PropelResultset Iterator Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-04 08:25:56 PDT
                                     Re: [propel-dev] PropelResultset Iterator =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-04 08:31:18 PDT
                                     Re: [propel-dev] PropelResultset Iterator Sven Tietje <mail at sven-tietje dot de> Sven Tietje <mail at sven-tietje dot de> 2006-10-04 11:11:24 PDT
                                         Re: [propel-dev] PropelResultset Iterator =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-04 11:20:35 PDT
                                             Re: [propel-dev] PropelResultset Iterator Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-04 11:29:47 PDT
                                                 Re: [propel-dev] PropelResultset Iterator Sven Tietje <mail at sven-tietje dot de> Sven Tietje <mail at sven-tietje dot de> 2006-10-04 12:26:37 PDT
                                                     Re: [propel-dev] PropelResultset Iterator Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-04 12:47:23 PDT
             Re: [propel-dev] PropelResultset Iterator =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-04 07:57:22 PDT
                 RE: [propel-dev] PropelResultset Iterator Sven Tietje <tietje at topconcepts dot de> Sven Tietje <tietje at topconcepts dot de> 2006-10-04 08:11:30 PDT
Page: of 2 « Previous | Next »
Messages per page: